philippe_44 wrote: > To a large extend, this is what I do with squeeze2upnp, as you know. It > shows LMS a proper squeezelite instance, receives the audio data, buffer > it locally and then offer to UPnP players a web server where they simply > 'GET' this buffered audio data with a bit of header addition/byte order > manipulation. Then it also does the control command / feedback > translation between LMS 'protocol' and UPnP 'protocol' (pause, stop, > seek, timing, metadata, format negotiation, volume, next track > handling). I wish in reality this is a simple as that, as their are many > nasty details, but the principle remains valid > > So, re-creating an HTTP stream for the chromecast device from the LMS > sent data would be very simple for me. What I don't know is how > complicated the control part is. > > For audio format translation, at the beginning I thought about doing > decoding/encoding inside squeeze2unp and the possibility is still here, > but I decided to focus on the mode where sq2u is more a simple forwarder > of audio data and let the LMS do the transcoding. This to say that > indicating to LMS what codecs are supported based on chromecast device > so that only acceptable format are sent is easy as well.
I looked at uPNP for LMS abput 8-10 yrs ago and found the incompatibilities between implementations too much as to make it impractical without buying many uPNP devices and testing. Since then DLNA and time has helped but I've admired your tenacity and perseveance to create a uPNP solution for LMS. Chromecast devices are simpler than uPNP as there are no onboard inputs but they are more customisbale than uPNP. A custom Receiver app (Javascript, HTML and CSS) can be loaded into a Chromecast device and so its control & behaviour can be made complex. The Default Receiver app is a basic media and so it simple media controls such as play, pause, stop, seek, skip, status (playing, paused, idle) as well as metadata - art, title , subtitle, duration. On top of that there is Application control which is about what Sender is in control of the Chromecast and what Recievr app is running. For example, typically if Chromecast is doing "nothing" and showing pitcure - it is running the Backdrop receiver application. My own initial thoughts about the solution was that since your upnp Squeezelite player works and since the underlying approach of Chromecast is very similar to uPNP (i.e. a http stream) - modifying Squeezelite would be the starting point. Since Squeezelite uses C++ - this would also help as the Protobuf compiler supports C++. While I have suggested that using the Defautl Receiver there are alternatives but probably technically more challenging and I'm not sure whether it would end up with a better solution. For example, it may be possible for a Custom Receiver to be written which implements Slimproto in Javascript which is run within Chromecast device. There is an issue about port 3483 traffic - not sure about security issues with Chromecast it may be possible to use Websockets to tunnel the port 3483 traffic to/from LMS but then rhis would also need some Websocket support to be added to LMS. ------------------------------------------------------------------------ bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=104383 _______________________________________________ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
