Bugzilla – Bug 9137
Boom Knob should behave like Transporter Knob...
Last modified: 2009-09-08 09:11:24 UTC
(feel free to adjust this to 7.2.1 if necessary... but I think it should be seriously looked at for the 7.2 launch). The Transporter's knob system works very well even in situations with a slow server (ie, readynas). Even when the network is lagged, it seems to know where you stopped the knob (such as @ Volume -34db) and as soon as the network catches up, it sends the right signal to get to that level. Boom on the other hand seems to send incremental updates that just say Vol UP or Vol DOWN. This means that with a slow network (and packets being dropped/ignored on purpose), most of your volume input disappears... You can turn the knob all the way around and it might only go up or down a few notches. The next time you turn it all the way around, it might go all the way up or down. This is very inconsistent and frustrating for the end user. Is there a reason why the two knob designs SHOULD behave differently?
Moving to 7.3 .... Will review after Boom release.
Personal view is that the TP protocol is probably the best way to address the congested network/server problem as it is self adapting to the performance available. It does mean that a bunch of stuff we've added into the server for 7.2 will need moving to the client though... Its possible there are shorter term options to improve the server performance though so it should be considered in parallel to server profiling on a slow box.
CC'ing Richard, who implemented most of the TR knob stuff. A simple approach would be to have the Boom firmware have only one outstanding knob event and when it sends a new one include a position value (which may be an absolute rotational position or a relative position since the last event). This is less than what TR does, as TR keeps track of the list size, etc... This way we're not queuing up tons of updates (causing overshoot in volume, for example).
I tend to think that implementing the full TP protocol would be best. I think the firmware for TP had a view of the full list which faced SC and then a back end which interfaced with the knob and reinterpreted this to meet the limitations of the TP knob? So could the back end be replaced for Boom? Reason for suggesting the full protcol is that it has things to deal with stale info etc by giving each menu list a number and sending the this back in the packets with index data in them. This avoids the problem of sending diffs over a link with a long round trip where you may get a move +20 back just after you push into a new mode, which will cause the display to jump for no good reason as far as the user is concerned. Rate limiting of one update per round trip is also a key part of it. It also means that we can remove the duplicated knob code in SC which does different things for boom than tp at present...
Doh, there will be no 7.4 - moving it to 8.0
Targeting based on engineering discussion Patches welcome