Bugzilla – Bug 8725
Fix 'Volume Control' in Boom to behave more like Transporter...
Last modified: 2008-12-15 12:39:24 UTC
Currently the Boom can easily flood the server with Volume commands by spinning the knob. This can cause timeouts and other strange behavior. Apparently we have some code in Transporter that we used to solve this same issue ... we should implement that in the Boom FW as well.
Maybe Sean knows in more detail what is magic about the Transporter that it doesn't show this issue.
Richard knows about TP I think. Adding him.
Is it the server or the tcp connection where the problem is occuring - i.e. is it due to lack of cpu in the server or network congestion? Is this for SN or a local connection too? Its most likely to be congestion for display messages to be sent to the player which backup when you spin the knob as each click of the knob creates a new screen update. TP rate limiting is to send one report of knob position per round trip on the slimproto connection. I am not sure this is possible with boom without implementing the TP knob protocol in boom as it would need to send position rather than left/right messages. It may be possible to do something in the server to avoid generating a screen update for every click through. Which input modes is this seen in most often? If you reproduce the problem - can you see the slimproto queue length building up on the Health web page for that player?
Boom, more than any other player needs local volume. Sometimes when the network goes out, you need to hit pause, or stop, or volume down, or whatever.... But the only way to affect it is to unplug it. Not very graceful.
Yeah, the problem this bug is meant to address is that exact scenario. I run into network hiccups quite a bit because I stream FLAC to the Boom and I'll see my volume, menu and other things slow down sometimes quite a bit. Its not that big of a deal with menu items, but not being able to lower the volume is quite an issue. My ideal scenario would be that when you turn the knob its actually raising and lowering the DSP volume ... even though there still needs to be network traffic to adjust the screen image the volume can still be adjusted and the screen will catch up as bandwidth is available.
So do you see the control queue build up to boom when you do this? If so then we can probably priorise packets sent from the server to the client over the slimproto connection. See Help - Server and Network Health - Performance Monitoring - Player, does the graph for the control connection build up?
I can't build up congestion in on the slimproto connection while playing flac and spinning the volume control - I assume you have a bandwidth limited connection Matt? If you can't see anything on this health measurement, then it probably means we can do anything simple in the server (other than simple rate limiting of messages) and need to do something which includes something in the firmware.
Felix, is this the bug that you already fixed with the packets?
This is related to bug 8227 (fixed in fw 20), which throttles wheel events, which is the best we can do unless we implement local volume control.
Verified with SqueezeCenter Version: 7.2 - 22900
This bug has been fixed in the 7.3.0 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.