In the functional specification subscription commands were mentioned, but till now nothing seems to be implemented. Are there yet any plans to implement that commands?

I'm writing an application using RCP to remote-control the SoundBridge and would highly appreciate to have an efficient way to get status changes.

Currently I'm doing this through polling which is not my prefered solution.

Could anyone of the Roku Developers give a quick status on this?

Marcus

Hi,

I found the answer in another thread - subscription commands are not part of version 3...

So I tried to poll for the necessary information and found a very strange behavior of the SoundBridge:

Sending a synchronous command the answer comes within 1ms, but only the first letter and the rest is delayed for about 200ms.

Example:

I send "GetVolume" and get a "G" after 1ms and an "etVolume: 20" after 200ms. This is far to slow!

Is this a bug of the current beta?

Marcus

Hi Marcus,

You didn't mention how your SoundBridge and computer are networked, but this could easily be due to network delays.

I would not recommend polling at such a high rate anyway. I don't think it would be a bad thing at all to update at a rate of once per second.

FYI, I also see that behavior on both 2.7 and 3.0, so this is not a 3.0 beta issue.

The first character of the RCP response comes back immediately, then the rest of the response comes after a delay. I haven't timed it, but it is slow enough to see the effect in an interactive telnet session.

Not a big deal IMO, since we have a polling delay anyway. But if this behavior is not by design, perhaps it can be modified to improve response time in the future, when we have "fast" subscription commands...

Cheers!

Hi,

sorry I missed some information:

I currently have 2 ROKU M1000 connected over a (Gigabit) switch with the Server. The latency in the network is < 1ms. It definitely looks like this is a behavior of the Soundbridge. It always answers with the first letter < 1ms and the rest of the telegram is sent after a delay of 200ms. I will check this with a network monitor to see what traffic is going through the wire (and if there are errors), but at the moment there is no obvious reason for this packet 'fragmentation'. Also other developers like zuovo in the previous post have confirmed this delay.

Basically the problem is that I'm not just polling for one thing. In my application I do the following polls:

- GetElapsedTime (~200ms/call)
- GetTransportState (~200ms/call)
- GetSongInfo (200ms/call) in a background thread to get more information about displayed songs.

All calls are currently done once per second.

If I now try change the volume through repeated SetVolume calls the changing of the volume reacts very slow and undefined.

Having an overall response time < 1ms for a synchronous call is not necessary, but < 10ms should be reached to have a system that behaves 'reactive' in every situation.

Marcus

It always answers with the first letter < 1ms and the rest of the telegram is sent after a delay of 200ms...Also other developers like zuovo in the previous post have confirmed this delay.

Yup. On 2 M1001s, running 2.7.78 and 3.0.34.

Since I already have delays from polling, wireless, and server, this is not a big issue for me. I would rather see Roku implement RCP seekTo/seekBy commands, or direct Pandora integration, or RCP-over-HTTP. But who knows, maybe this is an easy fix.

Basically the problem is that I'm not just polling for one thing. In my application I do the following polls:

- GetElapsedTime (~200ms/call)
- GetTransportState (~200ms/call)
- GetSongInfo (200ms/call) in a background thread to get more information about displayed songs.

All calls are currently done once per second.

What platform are you implementing this controller on? A delay for GetElapsedTime or GetTransportState should not be a problem if the client is smart enough to maintain this state itself.

I see how the cumulative delay might be a problem with GetSongInfo, though. If you want info for 100 songs, and there is an extra 200ms delay for each request, that adds up to 20 seconds...

If I now try change the volume through repeated SetVolume calls the changing of the volume reacts very slow and undefined.

Yeah, that sucks. If I understand this, your controller has volume up/down buttons that the user holds down to change the volume. Is that right?

Depending on your platorm, there may be a better UI for this. For example, I control volume in VisualMR/PocketPC using a pop-up menu of volume levels. What is your client platform?


HTH!

Hi zuovo,

I'm implementing this controller for the PocketPC. The controller should work as every other remote control for audio devices. The original ROKU remote is a good example, how changing the volume should work.

When I think of a controller, I think of a 'rich' client that brings the user all the available information (as fast as possible) and not just the song title.

And I want to implement a very reactive system. If there is an implementation bug then the ROKU developers should fix it, because in my opinion in the future the possibilites of the SoundBridge will constantly increase.

There might be more information for a client than ElapsedTime/TransportState/CurrentNowPlayingIndex/Volume in the future which could be polled frequently. With a delay of 200ms per poll you can do only 5 polls/second which then might not be enough. Therefore ROKU shouldn't give away any performance if there is no good reason.

Marcus

Well, I think one thing that will help a lot is when we're able to get some resources allocated to implementing the subscription commands. Once those are in, then the amount of polling required should drop, really, to zero.

I appreciate your desire to get detailed song info on every track, but we actually don't even fetch that information ourselves. We fetch the bare minimum required to be able to display, sort and play the tracks that we display, and beyond that the SoundBridge makes individual requests to the server to get info. I wouldn't depend upon this changing anytime soon.

If I get a little time to look at this, I'll try to figure out what's causing the delay. A question: is the behavior affected by whether the SoundBridge is currently playing anything? i.e. if you were to issue a Stop, then issue the same commands, is the latency different?

Hi Mike,

yes subscription commands would help a lot. My desire to get detailed song info comes from practical use: If you do a SearchSongs you often get the same song more than once.

One time it's a track on the original Album, and the second time it's part of a compilation of that artist and a third time it's part of another compilation containing songs of other artists too. In this case the user sees the same title 3 times. It would be great if I could list the songs at least with the album name for those cases, because that would help the user to distinguish these songs - that's what I'm thinking of when I use the term 'rich' client. At the moment I can do this through GetSongInfo, but it's not very performant.

I will check if I can provide more detailed information on the delay this evening.

Again I want to thank ROKU for the really big amount of new commands introduced with version 3. There are a lot of must haves that make life easier.

Marcus

@Mike - FYI, just eyeballing it, the behavior is the same to me whether the SoundBridge is playing or stopped. From a debugging perspective, I wonder why there *isn't* a delay for the first character. Why does the SoundBridge send that single byte immediately, instead of waiting until the whole response is buffered?

@Marcus - Maybe this is a silly question, but have you taken a close look at VisualMR? Thorsten has implemented a fairly rich PocketPC controller, and he is responding to enhancement requests. Maybe you guys could even work together on a new version....

Hi zuovo,

you won't believe it, but I'm already working since November 2005 on my controller (it's a sparetime project). Meanwhile I recognized that I'm not the only one working on a controller, but my approach will be a little bit different than the existing solutions. The screenshots of VisualMR look very promising, but I haven't tested it yet. There are also other UPnP controllers available that can control the SoundBridge but none of them had what I was looking for.

If I knew earlier about VisualMR I could have tried to contribute, but currently I have spend so much time with my controller, that I have the ambition to finish it.

One of the reasons why I'm so concerned about RCP-Performance is, that I've written my own graphics engine (in pure ARM-Assembler) that allows a lot of nice effects in the controller, but they are only possible if the corresponding RCP-commands are fast enough.

So stay tuned an see what the future brings...

Marcus

RokuMike wrote:

If I get a little time to look at this, I'll try to figure out what's causing the delay. A question: is the behavior affected by whether the SoundBridge is currently playing anything? i.e. if you were to issue a Stop, then issue the same commands, is the latency different?

Hi Mike,

I checked if there is a difference between playing and not and there is !!!

GetTransportState takes ~200ms if not playing (=state "Stop") and only ~40-80ms if playing (= state "Play").
Why is there such a big difference?
I was so focused on the problem that it didn't even think of starting to play the songs to see what happens

If the timing of the other synchronous commands is similar, then I can live with it for the moment. Nevertheless I hope that the subscription commands are available in the near future - it would make a lot of things easier and reduce traffic on the network.

Thanks a lot!
Marcus

I believe it. The journey is the reward, right?

imho VisualMR is almost perfect, but it sounds like you have some interesting new ideas! I would love to help test your program if you decide to release it - please let me know.

fwiw, one new feature I'd love to see is a virtual thumb wheel (think iPod) using the PocketPC touchscreen. This would be very useful to scroll through long lists of artists/albums/songs, also to change the volume, and hopefully in the future to seek within a song.

It sounds like you do deep PocketPC development, so maybe you could figure this out. I bet you could also sell it as a generic component to other PocketPC developers who want better UI for long lists (and who don't want to be totally left in the dust by the iPhone )...

</offtopic><ontopic>

It seems to me that RCP subscription commands are necessary for dumb-client displays (DisplayUpdateEventSubscribe) and to divert/patch the IR controller commands (IrDemodSubscribe), but not so much for transport events. The only case I can think of where you would really need SubscribeTransportUpdateEvents is for dueling controllers, which seems like a rare/contrived usage.

Otherwise, the controller already knows the transport state and elapsed time (b/c it controls the transport state), and it can get the total time of the current song, so it need not request this info from the server so frequently. Radio streams are an exception - you still have to poll if you want to display the current title of the stream - but a polling interval of 5+ seconds is fine for this. You probably won't pick up the controller to see what is playing until you have heard much more of the song anyway.

Just my 2 cents based on the use cases I know of. You might have others in mind...

Cheers!

I've used the SoundBridge enough with multiple control sources (via UPnP) that I think that subscription to transport events is pretty important. I find that I will fairly often do something like just quickly grab the IR remote to pause the unit when the PocketPC is in the other room, and so it's important for the displays to stay sync'd.

Hi,

I think there is no way round subscription commands in the future.
As Mike said it, to keep things in sync and to show correct states.

Example:
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.

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!

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.


As we can see there are a lot of reasons for subscription commands.

I hope they come soon...

Marcus