RokuMike wrote:

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.

Me too. We control our SoundBridges with 2 PocketPCs and 2 stock IR remotes, and I usually grab whichever device is closest (and hopefully cradled/awake). For everyday usage a long polling interval should be fine. If you grab one device, it is very unlikely that you will look at the display of another device in the next few seconds, even if it is on the same table. You have to be using multiple controllers ~simultaneously~ to really ~need~ pushed transport events. We have used both PocketPCs at the same time just for fun, but this is a very rare usage.

Of course, the device that I am using right now should update its display immediately. This is currently a minor quirk in VisualMR: you press a stateful button like play/pause, and the visual state of the button does not change for about a second. That delay would be ~partially~ solved by subscription to transport events, but you still have the network and SoundBridge latencies to consider. For the most responsive transport UI, imo, the controller should update its own transport state/display immediately instead of waiting for an event from the SB. Then it could poll at a longer interval (multiple seconds) for transport state changes caused by other devices.

Please don't get me wrong, I ~do~ want to see subscription/push for transport events (and for changes to radio stream metadata) eventually. I just don't see it as a near priority, relative to other features. And this is coming from a UI guy who uses multiple handheld RCP controllers every day...

BTW, have I mentioned lately that the SoundBridge is a shockingly great product, and your involvement in these forums is hugely appreciated? Well it is, and it is. Thanks for both.

Cheers!

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:

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.

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.

Hi zuovo,

my engine is currently 2D. To be precise it's not just an engine but meanwhile a complete framework with a lot of classes. I developed everything from scratch (Windows, Buttons, ListBoxes...). It's written in C# / C++ and ARM-Assembler, with the .net compact framework, but it doesn't make usage of any of the forms classes and the existing graphical stuff (GDI, GDI+) because this is currently slow.

On some devices the engine makes up to 200 frames/second, but more than 50 frames/second don't make sense because everything beyond the update rate of the screen can't be seen.
On newer devices (Windows mobile 5 and above) DirectX support is available, but the most existing devices have none. This is the reason why I had to write my own stuff.

From performance side something like CoverFlow is possible, but I have no album art yet, because RCP doesnt' provide a mechanism to get it. An alternative would be to get the data from Amazon (or other providers) but I haven't got the time to do this yet, because my resources are restricted. If I have all the other basic stuff running I could give it a try...

Nevertheless I tried polling for GetVizDataFreq between 10 and 20 times/seconds yesterday. It works somehow, but in most cases (especially with electronic music with high bpm rates) I loose peaks because of the low poll-rates, i.e. you hear a drum but you can't see it one the screen, because the peak takes place between 2 poll intervalls.

@RokuMike: Any idea how fix this?

Marcus

No good ideas, I'm afraid. We could potentially add a subscription-type command in the future to send viz data, but I suspect we'd almost want that to be on its own connection...

Marcus Venturi wrote:

From performance side something like CoverFlow is possible...

Wow! I thought this might require hardware graphics acceleration. If you can do this on a typical Pocket PC, I am very impressed. Of course I won't believe it until I see it...

Marcus Venturi wrote:

...but I have no album art yet, because RCP doesnt' provide a mechanism to get it. An alternative would be to get the data from Amazon (or other providers) but I haven't got the time to do this yet, because my resources are restricted. If I have all the other basic stuff running I could give it a try...

I think it would be awesome if you could collaborate with Thorsten in some way. VisualMR already gets cover art from Amazon, and it also does UPnP discovery, partial load of large lists, caching, skinning... It sounds like you can do some amazing stuff, but it will take forever if you have to duplicate all of this.

Marcus Venturi wrote:

Nevertheless I tried polling for GetVizDataFreq between 10 and 20 times/seconds yesterday. It works somehow, but in most cases (especially with electronic music with high bpm rates) I loose peaks because of the low poll-rates, i.e. you hear a drum but you can't see it one the screen, because the peak takes place between 2 poll intervalls.

It sounds like you want your visualizer to do beat detection, so you can actually see e.g. drum beats? Accurate beat detection is difficult even when you have the raw audio stream to work with. Ideally you would run a FFT on every 25ms of samples, psychoacoustically partition the frequencies into at least 64 subbands, and then compare the energy of each subband sample against the average local sound energy for that subband. But you don't have all the data, and seems unlikely that the SoundBridge would ever do this much work for a visualizer.

IMO, if you can't do real beat detection, you might as well just show a random animation while the music is playing. The end result will be about the same. I doubt that many people will look closely at a handheld visualizer anyway. Personally I only use visualizers when they are projected on a rather large wall of the room where the music is playing.

Mike,

just to keep things going...

I am waiting anxiously for the subscription commands too.

Just this week, I had contact to ControlWorks and, unfortunately, they refuse to do any enhancements to the Crestron module until subscription commands have been implemented. So the new features and enhancements of ver. 3 won't be available to me and I would have to downgrade my SoundBridges...

Therefore, please put in a good and strong word for implementing subscription commands anytime soon. I really would hate to swap my three SoundBridges für SlimDevices...

Thanks!


Markus

Hi Mike!

Any news on the pending implementation of the subscription commands?

Thanks and a happy new year!


Markus

Hi Markus,

RokuMike has left ROKU in September 2007.

http://forums.rokulabs.com/viewtopic.ph ... ght=#82782

Subscription commands have been announced since a long time in the RCP-Documentation, but nothing happened yet.
There are a lot of other "on hold" topics that I would like to see in the next versions, because they block somehow my development.

- Start playing at a certain position, FastForward/Rewind

http://forums.rokulabs.com/viewtopic.ph ... ght=#79897

- GetAlbumInfo (This is very essential!)

http://forums.rokulabs.com/viewtopic.ph ... ght=#85905


In the past I was used to get answers for developer requests from RokuMike, but since he has gone there is no answer to the most developer requests at all.
There is a somehow chaotic "Feature Request Forum" for "End users" were you can find that even they want features like FastForward/Rewind like in this post:

http://forums.rokulabs.com/viewtopic.ph ... sc&start=0

But again there is no answer from ROKU at all.

I've already spend 2 years of "spare time" for my application and my goal is to go into beta this spring.
But before I go on I wanted to know if ROKU is still alive and development is going on, and perhaps where it's going to.

There should be a public "list" of requested features were developers could vote for topics. The most wanted topics should be done first.
This would make the process more transparent for us. Doing this only via the forum is somehow too chaotic.

A Happy New Year from me too...
Marcus