Chromecast Audio as endpoint? [Delivered; B333]

Does this effectively translate to ‘Roon has made it clear there will be no support for CCA’? Not read the full thread so genuine q btw.

I’m assuming not and that there’s another way to support CCA, otherwise the topic would be closed as not on roadmap - like the recent folders thread.

Is the comment from G_P re APIs not relevant here?

The way I remember delayed CCA support, is/was that Roon hadn’t developed CCA support as they weren’t sure if Google would ‘move the goalposts’ in some way.

Freely admit i’m out of touch on the topic but still have my 2 x CCAs ready to go when Roon is…

That’s really my question.

I am not technical enough to know what the options are with Chromecast. Other players do this with UPnP. It is a given that roon will not. I also would like Chromecast support but I would prefer to be realistic. This thread has been going for a very long time. So I am just throwing the question out there. Is anyone aware of alternative ways of doing it?

If Roon can do Airplay why not Chromecast its becoming one of the industries standards and will open up a whole other lot of devices to the Roon ecosystem, other than Googles little puck and considering it can handle upto 96/24 it seems rude not to. Gapless can be an issue but this it seems can be done if its implemented right.

@r_t, @CrystalGipsy, a guy called Phillipe seems to have done exactly that. So I have answered my own question. There is a recent Airplay to Chromecast driver on github. The guys in the tinkering section in this forum have been playing with it. I am not a very technical person but for windows its quite straightforward. I got it working and I am streaming to a regular Chromecast (not Chromcast AUDIO) right now from roon. Sounds much better than I thought on a newish flat screen TV.

When you run the executable, it opens a window and you see it attach to your Chromecast. You can minimise the window and I think you can run it in silent mode once you have got everything working. But I haven’t got that far yet.

It then shows up in your roon devices as an Airplay device and you just enable it normally

Then play something. Roon seems to be down sampling me to 24/44.1 but I think that is because I am a regular Chromecast, not a Chromecast AUDIO. In the context in which I am playing it still sounds very good.

This is not for everyone. It’s a 3rd party solution for the tinkerers. It’s a very early release. You will probably have to make an exception in your anti-virus for example. There is no display of artwork or track playing on the TV.

I’ve had it playing for several hours now. No drop outs, no pops, crackles. Seems very stable. I would be interested in the experience of anyone who gets this working with a Chromecast AUDIO on a better quality system @ 24/96.

Chromecast support is still on the Roadmap, meaning Roon intend to implement it. Chromecast is a different protocol than DLNA so the firm “No” regarding DLNA does not rule out Chromecast.

There are complexities that mean it hasn’t happened yet, but nothing so far that would mean it can’t be done.

There is no news as to timing.

Audio wise, the second gen Chromecast is no less capable than the Chromecast Audio. Same internal hardware. The former just has an HDMI output, while the latter has a TOSLINK output.

And the 16 bit 44.1 kHz downsampling is due to AirPlay, not Chromecast, Remember, this solution is using the AirPlay protocol with its inherent limitations.

AJ

Thanks for clearing that up. I’m just playing to a maybe 5 year old Samsung flat screen. The model no. isn’t obvious. I cannot reliably distinguish above redbook any way, even on a good system.

Still curious to hear other’s experience. It wouldn’t be difficult to cobble something together better than I am playing on. I must say it really seems very stable. So far I am impressed. A good temporary solution for some I think.

Gave this a try tonight and found that it only located a ChromeCast Audio device and two sonos speakers which are already in the system. It’s not seeing any additional cast devices on the network … I have two Nvidia shields and 7 (1 standard, 6 mini) Google homes floating around in various rooms. Interesting that the Homes and Shields are not visible …

Yes. I thought there might be limitations. Very early release. I have a very simple travel use case. Laptop->Hotel TV. Is working very well for that.

When you say it located CC’s already in the system what have you been using before? I’ve tried a few things. JRiver WDM for example, but this is the only thing I have been able to get working.

That Phillipe keeps himself busy with these little plugins. I used his upnp one when I just used Squeezebox to play to some Pure Jongos I had for the garden. Worked well.

I didn’t have any CC in the system before … I meant that it sees my Sonos (already on Airplay) and is offering them as airupnp

Thanks AndyBob, understood re timing.

When you say - There are complexities that mean it hasn’t happened yet

And G_P says - Chromecast API is open and anybody can write an application that casts to Chromecast without asking google for permission to do this

Also as a general observation - there do seem to be a lot more apps out there now that offer casting as an option.

Are you able to give us some more detail as to why its not as straightforward as G_P and the broader application support out there suggests please?

I disagree with the assertion that this is simple for Roon to implement because “the API is open”. The API is documented and an implementation provided for certain OS’s (android, iOS, Chrome). The implementation is not open and has been reverse-engineered for some platforms by 3rd parties, not Google. These reverse-engineered implementations are unsupported and can break at any time when the SDK changes.

There is no SDK for desktop, which makes it rather challenging for Roon to implement the same functionality across all its platforms.

-mike

1 Like

I don’t know that detail. I’ll flag @brian to see if it’s something he can share, but the Forum may not be the best place to discuss unresolved technical issues. Mike’s comment above sounds likely.

Ok thanks AndyBob.

Some additional context, I see the new version of VLC - V3.0 that I downloaded earlier this weekend now supports casting from the Mac.

I tested it for basic capability and it works well over wifi to my CCA - no glitches that I could see so far.

Is it Roon level sound quality - since I only listened for a short while then I couldn’t say. Seemed good enough to cast to the kitchen / less critical environments that a CCA might most often be used,

I thought Chromecast worked like Spotify connect. When you cast from Hulu or google etc, you are using your phone or browser like a remote control to command an audio or video stream to be sent over the internet to a Chromecast end point. When you cast using the API or a browser, your Chromecast application sets up a webRTC connection to the cast end point {Chromecast dongle for example} and then streams over your network. This latter option is not going to be hifi and will use a lot of processing power on the sending device. WebRTC is like setting up a second stream from the server or laptop. So a roon server would need to set up a webRTC session to every Chromecast end point and stream over your local network to these end points. Firstly quality would be low and isn’t that why we have RAAT?

I did a bit more digging. And yes Chromecast has two methods of operation.

Firstly using the API. This method requires the sender to be white listed by Google and approved. Sources such as Netflix, Hulu, Spotify etc have already been whitelisted (and for now Google are not accepting anymore applications). To use the API, you cast to a Chromecast receiver (dongle etc) using an App or web browser to first discover the end points on your local network using Discovery and Launch protocol (DIAL) which uses UpNP to find devices on the local network. WHen you cast to these a stream is sent from the sender (Spotify, Netflix etc) to the Chromecast device on your network. I think it would be impossible to use this method to cast from Roon as all our servers would have to be white listed.

The second method is a bit of a kluge and uses WebRTC and HTML5. Basically an Application or Chrome Browser (like VLC) on a phone or laptop/tablet uses DIAL to find end points on your local network and then sets up a webRTC session to one or more of these end points, it then takes an existing stream on your device (like your Roon Application or a local video), re-encodes this into a webRTC stream (Chromecast supports Audio codecs HE-AAC, LC-AAC, MP3, Vorbis, WAV (LPCM), FLAC & Opus) and shoots it at the selected Chromecast endpoint. So lots of load on your device and on the network (two streams, one from Roon server and then another from the device to the Chromecast endpoint). In essence Roon Server decodes your FLAC/AAC/WAV file and sends it using RAAT/Airplay to your DAC/PC/MAC etc, the this sends this stream to the application that will re-encode it and wrap it up in a webRTC stream to send to the Chromecast device.

IMHO the only way Roon could make this work is to build a webRTC sender into the Roon server so you could cast direct from that. This of course would mean that Roon would either not decode the stream (if it was FLAC for example), or transcode it from a format like OGG into one that Chromecast supports (say FLAC), wrap this in a webRTC stream and send it to the Chromecast. And then of course all the Roon Apps would need to be able to use UPNP to find the chromecast devices and tell the roon server to cast to one or more of them.

It might be better to search for another cheaper end point that uses Appletalk or RAAT rather than wait for Chromecast support.

3 Likes

Thanks for laying out all of that detail Robert - not seen that anywhere else at all.

I think for some of us, the 2 x streams may not apply - iiuc in my set up with my core / control being on the same mac and my files on a local disk then there’d be one stream to the CCA - assuming I’ve understood properly.

I had a look at the processor usage and I didn’t see anything significant when VLC was casting, though of course it only allows casting to one endpoint.

I didn’t try 2 instances of VLC running - to cast to 2 endpoints but then you’d be running 2 full application stacks which would be an overestimate on processor usage and in any case Roon isn’t VLC so not really a fair comparison.

I keep coming back to a simple view, if others can make it work sufficiently well, then so should Roon. I suppose thats the bottom line for me, as someone who isn’t familiar enough with developing applications to have a more informed view.

Thanks again though, for doing the digging and documenting how the support of casting works.

Not sure how this will show on the site, but I have tried to put this down as I understand it with a few diagrams.

Firstly, using the API/White List scenario.


If you use Spotify now, then this is how it works with Chromecast. The user launches Spotify, logs on, selects a song/play list, The spotify App scans the network for spotify ready end points and Chromecast end points and presents them as available devices, the user presses play and the song is streamed directly from Spotify to the users end device, the mobile/desktop app just acts as a remote control and performs no audio processing. Google has a number of whitelisted services and note that the content is streaming from the cloud, not the local network.

Then using the Web RTC option as I believe VLC does


The user launches VLC, VLC scans the network looking for devices using uPNP and DIAL. The user selects an endpoint from the discovered list and VLC or the application sends the raw data to the Chromecast device and the Chromecast device turns it from Digital to Audio using its DAC (FLAC stream for example).

The App isn’t doing any work, the device is streaming the source file from its local storage or from a network share, so the device is doing a bit of work at this stage.

Then a possible Roon scenario which loads the server and therefore not every Roon application. Note I have no idea what the Roon guys are thinking of at this stage and I have nothing to do with Roon other than being a happy user.

In this scenario the roon server would do a background scan of Roon compatible end points as it might do now. On discovering a ChromeCast end point it adds it to the list. The user picks a play list and chooses an audio zone as they do now. The roon server has to decode the source file from FLAC (or whatever), apply any user selected signal processing (Equalisation, room correction etc) and then has to re-encode the resulting audio file into a format the Chromecast device understands such as FLAC/MP3/AAC etc. The Roon server then streams the resulting FLAC encoded file to the end point. At this stage note that the Roon Server would be decoding the original file, applying corrections and then re encoding the file all on the fly which would be a ton of work for the processor and I am not sure if it would be possible. The alternative would be for Roon not to decode the file at point (d.) and simply stream it to the Chromecast device (g.) which would be less work, but might break the Roon model.

All of the above are just my thoughts on the whole Chromecast thing and may be totally off base, so just something to think about.

2 Likes

Great diagrams and explanations, Robert.

If WebRTC would require Roon to serve encoded files to Chromecast endpoints, I suspect that to be a no go. Philosophically, Roon is built around serving PCM and DSD gapless streams – in decided contrast to the file based approach of DLNA/UPnP.

AJ

1 Like