Hi Marcus - Sorry, missed your last post when I replied yesterday. I totally agree that subscription commands are the only solution for some things, like raster display updates. And they would be nice to have for the transport events eventually. A few other comments...
Marcus Venturi wrote:
A controller initiated playing of a song. While playing that song you have a play button that displays "pause" to show you, that you could pause the song. If you now press that button, the application will display "play" to indicate that the system is now in pause mode and you could continue the song by just pressing the button again.
But what if something with the RCP command went wrong or is delayed? In this case it would be better to first ask the SoundBridge what the current state is - and if everything is ok - display that changed state afterwards. If the state is not as expected the controller could repeat a command.
Hey, we both used the same example.
Just a different perspective. Here is my reasoning for changing the button immediately, instead of waiting for the SB:
1) Failure to play or pause in a timely manner should be very uncommon. Most people will be unhappy with a 1% (1 in 100) error rate for these commands. So it does not make sense to compromise the responsiveness of the UI for this uncommon error.
2) If a transport error/delay does occur, the big disruption for the user is the failure or delay in the ~audio playback~. The button state is relatively unimportant. If anything, I would say that the button did the right thing but the audio did not respond.
3) Psychologically, people have a higher tolerance for audio delays than for visual delays. So if you have a choice between a short audio delay or a short visual delay, in general, choose the audio delay. It is much more likely to go unnoticed.
Marcus Venturi wrote:
And of corse there exists the use case that the roku is playing a list of songs while the controller is constantly polling to check what song is currently playing. Instead of polling every second it would be better for the client to be informed if the next song is played. In this case only one message goes over the network.
And this can save a lot of network traffic!
This frequent polling is mostly an issue for multiple controllers, or stateless controllers. In theory, a smart single controller could fetch the playlist and song info up front, then poll the SoundBridge only every minute or so to maintain synch. Unless your songs have bogus duration tags...
But anyway, even polling every second, the network traffic is very light. GetCurrentSongInfo returns about 1KB, so 8kbps of data bandwidth. Meanwhile a single audio stream is 128kbps to 1.4Mbps.
A bigger issue imo is handheld battery life. I sometimes switch applications when I put down a PocketPC controller, so VisualMR will stop polling for updates. But this is not a huge difference - maybe another 5 or 10 minutes of battery life. Extended batteries and good cradling habits are much more important.
Marcus Venturi wrote:
Just imagine that an application is displaying a frequency analyzer. To do this fluently, it needs to do 20 polls/second,
i.e. 20 times sending a command from the controller to the SoundBridge and 20 times receiving the result from the SoundBridge.
If that could be handled with a subscription command, by telling the SoundBridge "Just send me the latest frequency data every 50ms" it could reduce traffic on the wire because then there is no necessity to poll 20 times /second.
And - not to forget - synchronous commands mean that the communication channel is blocked for other commands till the SoundBridge is ready to deliver the data.
What if I call GetVizDataFreq right at the wrong moment moment were the SoundBridge is not ready, perhaps just because some data is available 30ms later?
In that case the SoundBridge will delay my call at least by additional 30ms till it has the data and then send it back.
If this is done by subscription, the SoundBridge will decide when to send the data - locically when it's available.
Wow, visualizers on a wireless handheld controller!
Very ambitious stuff. I see why you would want subscribed events for this. You already have to eat the delays from wireless hops and the visualizer rendering.
If Roku implements subscription commands for viz data, hopefully they will do it the way you suggest, not the way subscription display updates work today. DisplayUpdateEventSubscribe does not turn on a continuous stream of updates; you need to call GetDisplayData each time to get the data (and implicitly request the next update). So you still have the traffic and blocking issues you mention above.
But forget visualizers for a second...this has me wondering...is your graphics engine capable of doing something like CoverFlow
for album art? That would be really amazing.