philippe44
Adapting CastBridge for DIAL/Roku
I want to resurrect LMS support for some Roku devices I've got. Did Castbridge at any point support the Chromecast V1 protocol with DIAL? Any recommendations for where to start?
Thanks for all the great work extending LMS!
No I never did that. The initial version was using UPnP discovery protocol and then they/I moved to mDNS, but the streaming has always been V2. I don't know dial, so it's difficult to tell you where to start. The model of the bridges are a full slimdevice side that spits out audio (decoder or raw) into a ringbuffer. The "other" side is usually an HTTP server that reads that ringbuffer and provides it to client. There is also a control layer that translates LMS request into native ones and adds metadata and al. So you would have to 1/ change the data layer of HTTP server is not DIAL model and then change the control layer to translate LMS commands and report progress and other unsolicited events back to LMS. The architecture is reasonably flexible, but still it was done on my spare time.
Alrighty. Thanks for the quick response.
Netflix has a document outlining DIAL discovery protocol, but it appears to be oriented around launching supported streaming services. That means part of the battle would be deciding on which Roku "channel" to use in order to obtain the most deterministic audio latency.
Service discovery is purely by SSDP, so reasonably straightforward. Both DIAL and ECP are listed, although ECP might be the more flexible option. An audio playback program can be launched with one http request then primed with key/value pairs via another http request. Status information can be polled via a third http request.
Any thoughts, especially with respect to dealing with latency issues? Also, would you prefer this kind of initial ruminating go here or elsewhere?
So, in short, the data layer could simply publish an mp3 object to be eaten by, for instance, the Shoutcast channel with ECP as the bidirectional control channel.