• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

Review and Measurements of Chromecast Audio Digital Output

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
45,613
Likes
252,476
Location
Seattle Area
This is a review and detailed measurements of Google Chromecast Audio digital output. The Chromecast is a tiny dongle that allows one to "cast" (stream) audio and video to a remote device. The audio version as the name implies, foregoes the video functionality and provides audio streaming. The retail cost is $35.

Chromecast Audio has dual outputs in the same 3.5 mm jack. One is the standard stereo analog. The other, by use of a cable you need to buy, is Toslink digital optical output. The appeal, and the scenario for testing in this article is that by addition of the Chromecast audio to your own DAC using Toslink you immediately turn your DAC into a networked streamer. Concern however has been raised that the Toslink output has too much jitter to be a good interconnect. In this article, I will be digging into this aspect of the device. In a future article I will measure its DAC and analog output performance.

The Chromecast Audio is a tiny round dongle. It has a USB jack for power and the aforementioned 3.5 mm jack. Here, you see it connected with my switching USB power supply and the special Toslink to 3.5 mm cable:

Google Chromecast Audio Digital Output Review and Measurements.jpg

The device requires setup for its Wifi functionality which I won't dig into. After that, in my admittedly limited testing it has proven to be very reliable in being recognized and streaming audio.

I have procrastinated testing the Chromecast Audio because I was not happy with using Google Cast software due to fear of it not being "bit exact." The protocol Google uses for streaming is proprietary so until recently, you were stuck with whatever opaque data path Google provided. Previous tests used PLEX media server which I have also used in other testing but I still preferred to use something more known and better.

Enter Roon's support of Chromecast audio as a remote audio device. Since I use Roon for my personal music enjoyment and for testing devices that don't act like a sound device in Windows (i.e. all networked streaming/rendering DACs), I was very happy to read that Roon can now talk to Chromecast Audio. How well was something I needed to figure out.

Let's get into measurements and answer these questions.

Measurements
Guessing that Google's CAST protocol or software is limited to 16 bits, I created a 12 kHz tone at that bit depth for test of jitter and noise. Jitter's amplitude is proportional to frequency of source material and hence the high frequency of this tone (relative to common 1 kHz we use for other measurements).

For the test setup, I connected the Chrome browser to my Chromecast audio and dragged the above file to its window. That gave me a plain play/pause control which was fine for this purpose. At connection time it asked for the volume and I set that to max. I connected the Toslink output of the Chromecast Audio to the input of my APx555 Audio Precision analyzer Toslink input.

Here is output comparing the Chromecast output (red) compared to APx555 playing the same file over its Toslink output (blue):
Google Chromecast Audio Toslink Jitter and Noise Measurement.png


Yuck! We have a massive transformation of our simple 12 kHz tone. Tons and tons of distortion spikes are added along with heavily modulated noise floor. Fortunately a lot of it is either at low amplitude or masked by the main tone. Assuming they amplitude of distortions is signal dependent, then they are not as audible as the graph indicates. Still, we don't want to see this level of degradation in such a simple tone. Even if there is lossy compression going on (which I suspect there is), a pure tone should be encoded perfectly since it is so easy to compress.

Lossy codec testing is almost always done using listening tests. But some measurements should be performed to make sure simple scenarios such as flat frequency response and distortion free (or close to it) is achieved with simple tones. Clearly this is not done by Google which is a shame. So forget about 24 bit audio, we can't play 16 bit audio properly here.

Fortunately as I mentioned, I had Roon to test so I powered that up, and went all out using my 24-bit J-test file:

Google Chromecast Audio Toslink Jitter and Noise using Roon Measurement.png


As we see, the results are identical to a whopping -375 dBFS!!! The APx555 internal audio representation is 32 bit floating point so it is able to achieve very low noise floors as you see.

The spikes are supposed to be there by the way. J-test signal toggles the low order bit at the rate of 250 hz which when decomposed into frequency spectrum, will have 250 Hz tone followed by odd harmonics forever. Normally you don't see this because it is buried in the noise of analog measurements (and addition of dither).

What this says is that we have perfect digital capture at 24 bits/48 kHz sampling through Roon. This allows us to then perform our standard measurements and not be limited by the audio pipeline. To that end, let's connect the Toslink output to a Topping D50 and measure its analog output and see how the two sources compare:
Google Chromecast Audio Toslink Jitter and Noise using Roon and Topping D50 DAC Measurement.png


Since we are measuring analog output, we see aberrations such as mains contributions on the left. And a couple of jitter spikes around our main tone. Important thing here though is that the results are identical whether I use APx555 to source the bits or Chromecast audio driven by Roon. The Chromecast Audio is not at all the limitation here and is as transparent as it needs to be.

Now, the blogger Archimago found jitter to be higher in Chromecast Audio than other sources he used. His test DAC was the Teac UD-501. I tested another variation of that DAC and it is not as well behaved as the Topping DACs are (see https://audiosciencereview.com/foru...asurements-of-teac-nt-503-networked-dac.2028/). I don't have the Teac anymore but do have a Schiit Modi 2 Uber which from prior testing, shows willingness to let noise on its inputs to bleed into its output. Here is how that comparison stacks up:

Schiit Modi 2 Uber DAC driven via Chromecast Audio Jitter and Noise Measurement.png


Now we see that the Chromecast Audio's Toslink output (in red) is indeed more "jittery." Here it is even more so than the Teac UD-501 that Archimago tested because the Schiit Modi 2 Uber is a lesser DAC.

Conclusions
There are a few here:

1. The CAST audio functionality of Google Chrome is horrid. There is no excuse for it to be butchering even simple 16-bit signals as it did. While audibly it is not as dire as it looks, I still would avoid it if you can.

2. Roon's implementation of Chromecast streaming is superb. It is bit accurate up to 24 bits and 48 kHz that I tested. Congratulations to Roon for job well done. I assume they received support from Google to implement it as the protocol otherwise is not open to the public.

3. The Chromecast output has more jitter than an audiophile/instrument grade Toslink output. This is evident when used with low quality DACs like Schiit Modi 2 Uber.

4. Using a well-designed Dac like the Topping D50, there is no difference at all between Toslink from Chromecast or higher fidelity sources. All the jitter is filtered out resulting in the performance of the DAC itself being the limit.

#4 is a great news here. It means that if you have a good DAC and use Roon, you can turn your DAC into a streamer/renderer using the Chromecast Audio. For just $35, that is a superb addition. As such, the combination of Roon and Chromecase audio is highly recommended!

EDIT: bit-perfect playback is also supported in Android apps like Hi-Fi Cast. See: https://audiosciencereview.com/foru...omecast-audio-digital-output.4544/post-102185. So you are not just limited to Roon.
-------------

As always, questions, comments, recommendations, etc. are welcome.

If you like this review, please consider donating using Patreon (https://www.patreon.com/audiosciencereview), or upgrading your membership here though PayPal (https://audiosciencereview.com/foru...eview-and-measurements.2164/page-3#post-59054).
 
Last edited:
BTW, here are the Topping D50 results when driven through Chromecast Audio and Roon:

Google Chromecast Audio Toslink through Roon Dashboard Measurement.png


It is essentially identical to driving it with my APx555 analyzer:
Topping D50 Toslink driven by APx555 Analyzer Dashboard Measurement.png
 
I am confused. Why there is no jitter when Roon->CCA->AP/toslink (the -375 dBFS inversed blue comb graph), but then there's jitter when Roon->CCA->Modi->AP/analog ? Doesn't it say that the jitter happens inside the Modi and not due to the CCA's toslink output? Or is the blue comb graph there only to demonstrate we get bit-perfect path through Roon and has little to do with jitter?
 
Last edited:
Good to see a proper DAC fixes it's small issues, it's a handy gadget to have, and is often on sale, I got mine for £15. I expect using it for Spotify or tidal gives correct performance, where as casting from the browser looks to be a hack job.

Can you test 24/96, I believe it supports that as well.
 
Was the browser cast test done with a 44 or 48 source file?
 
Good to see a proper DAC fixes it's small issues, it's a handy gadget to have, and is often on sale, I got mine for £15. I expect using it for Spotify or tidal gives correct performance, where as casting from the browser looks to be a hack job.

Can you test 24/96, I believe it supports that as well.

If it supported gapless playback it would have been perfect.
 
Awesome review! I've been watching Katana DAC for my streaming setup, but after looking at this, I think I'll have to reevaluate my options a bit.
 
It's gapless in roon.

This is likely fake gapless which only works, kind of, on low-latency connections, i.e. streaming over LAN. Spotify and Tidal weren't gapless through CCA last time I tried.
 
Last edited:
This is likely fake gapless which only works, kind of, on low-latency connections, i.e. streaming over LAN. Spotify and Tidal weren't gapless through CCA last time I tried.
Fake gapless?

Roon is perfectly gapless via the Chromecast, and mine is on WiFi, I don't have any other way to use it. Roon care about this stuff, and I think they fixed it in a very obvious way.

Tidal does still have as big gap, just tested it.
 
I am confused. Why there is no jitter when Roon->CCA->AP/toslink (the -375 dBFS inversed blue comb graph), but then there's jitter when Roon->CCA->Modi->AP/analog ? Doesn't it say that the jitter happens inside the Modi and not due to the CCA's toslink output? Or is the blue comb graph there only to demonstrate we get bit-perfect path through Roon and has little to do with jitter?
In the digital input case, the data stays in digital domain into the graph analysis. For that reason, as long as jitter does not cause data drops, it will never appear.

In contrast, when fed to a DAC and its analog output is analyzed, jitter can modify the DAC clock, reference voltage, or its analog output, all of which shows up in the FFT.

In other words, in digital audio, the only time jitter is a performance problem is when we convert it to analog. As long as it says in digital domain, it doesn't matter. The traces in your computer for example have jitter. Yet moving data around there is immune to such interference (again, until it causes data errors).
 
Device needs to start buffering next track before the current one stopped playing for gapless. My understanding CCA can't do it. Perhaps
In the digital input case, the data stays in digital domain into the graph analysis. For that reason, as long as jitter does not cause data drops, it will never appear.

In contrast, when fed to a DAC and its analog output is analyzed, jitter can modify the DAC clock, reference voltage, or its analog output, all of which shows up in the FFT.

In other words, in digital audio, the only time jitter is a performance problem is when we convert it to analog. As long as it says in digital domain, it doesn't matter. The traces in your computer for example have jitter. Yet moving data around there is immune to such interference (again, until it causes data errors).

Right, that does make sense and what I thought it should be. What threw me off was the very first graph with the title "Jitter and Noise Spectrum over Toslink Optical digital Link", and it was also an all-digital connection same as the second one, so I thought you were somehow trying to analyze jitter in time domain. What the first graph really shows is how the crappy of a job Chrome does for compression/resampling .
 
Fake gapless?

Roon is perfectly gapless via the Chromecast, and mine is on WiFi, I don't have any other way to use it. Roon care about this stuff, and I think they fixed it in a very obvious way.

Tidal does still have as big gap, just tested it.

Perhaps Roon manages to supply an endless stream to the CCA mitigating gaps. I looked into it briefly, Google claims CCA has everything to support gapless and it is up to the providers to integrate properly (which they don't). So I guess this is more of a Tidal or Spotify problem than the CCA itself, which however makes little difference for the end user.
 
I think a re- test at 48khz is in order for non roon use.
 
Perhaps Roon manages to supply an endless stream to the CCA mitigating gaps. I looked into it briefly, Google claims CCA has everything to support gapless and it is up to the providers to integrate properly (which they don't). So I guess this is more of a Tidal or Spotify problem than the CCA itself, which however makes little difference for the end user.
I'm sure roon uses the endless stream solution, it's the obvious approach given their architecture, and the cast notification backs this up. This is how I assumed they would do it since it was first put on their roadmap.

I've seen the stuff from Google about making it work, but I'm not sure I trust them to really know what gapless is.

P.S. When I tested gapless in lossy formats years ago WMA Pro was the clear winner. @amirm was that deliberate or fluke?
 
I'm sure roon uses the endless stream solution, it's the obvious approach given their architecture, and the cast notification backs this up. This is how I assumed they would do it since it was first put on their roadmap.

I've seen the stuff from Google about making it work, but I'm not sure I trust them to really know what gapless is.

P.S. When I tested gapless in lossy formats years ago WMA Pro was the clear winner. @amirm was that deliberate or fluke?

Google says that there are partner-provided player apps on the CCA itself, i.e. they are bundled in firmware, and these apps must make certain API calls for the gapless to take place. I also got an impression that the data stream must have some sort of gapless-enabling metadata in it as well. Does Roon require a recent firmware revision on the CCA? If so it is possible they in fact implemented a roon player/gapless solution on the CCA itself and not generating an endless stream on the Roon machine. Can't you play Tidal through Roon and it's not gapless?
 
Back
Top Bottom