• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required as is 20 years of participation in forums (not all true). Come here to have fun, be ready to be teased and not take online life too seriously. We now measure and review equipment for free! Click here for details.

Review and Measurements of Chromecast Audio Digital Output

gvl

Addicted to Fun and Learning
Joined
Mar 16, 2018
Messages
560
Likes
180
Location
SoCal
#61
What is not yet determined is whether some of the Android player apps that work with the Chromecast (including higher sample rates) are jittery or not? They might well be an alternative for some people without needing Roon. Android phone or tablet already in someone's possession would perhaps do the trick with the inexpensive CCA.
CCA's jiiter is a property of the CCA and not that of the source. CCA buffers the stream and the jitter is just a product of the crappy onboard Toslink transmitter it has. Sources may choose to compress the stream before sending it to the CCA which will lead to loss of fidelity as it happens with Chrome, this would be interesting to test, but this loss of fidelity is not jitter related.
 
Last edited:

Blumlein 88

Major Contributor
Joined
Feb 23, 2016
Messages
4,382
Likes
2,682
#62
CCA's jiiter is a property of the CCA and not that of the source. CCA buffers the stream and the jitter is just a product of the crappy onboard Toslink transmitter it has. Sources may choose to compress the stream before sending it to the CCA which will lead to loss of fidelity as it happens with Chrome, this would be interesting to test, but this loss of fidelity is not jitter related.
Playing the Chrome browser we have the graph below. Suspected by Amir to be a lossy codec, but not confirmed. I don't want that. This from the toslink output of the CCA.

Playing via Roon and the toslink output to a Topping DAC we have this. One color is via Roon then CCA to the Topping and one is from the AP unit to the Topping. Pretty much identical.



So my question is, if we use an Android app designed to work with the CCA and use the toslink out do we get the first or second result?

If you don't already have Roon, the cost of it to use the CCA effectively is a real deal killer. If instead I can get the CCA for $35, and use a music app that costs less than $10, getting the same quality result then we may be onto something.
 

gvl

Addicted to Fun and Learning
Joined
Mar 16, 2018
Messages
560
Likes
180
Location
SoCal
#63
^^^ The first graph is all digital, it is not jitter. The printed title is misleading. But I agree it is interesting to see if playing from an Andoid device yields a similar mess due to compression.
 
Last edited:
Joined
Jul 25, 2018
Messages
9
Likes
11
#64
Hi Amir, thanks again for offering up the measurements on such a widely used device. It's often recommended on reddit so it's nice to see that it performs well.

Regarding the mentions of jitter here and in other reviews, I have some concern of how they might be interpreted. Using a single visualization to show jitter and noise spectra seems to mix the testing intents. Measuring clock jitter and noise should be treated separately so I would expect to see a true J-Test (with LSB toggle at Fs/4) for jitter but use a higher FFT sample to capture noise. Jitter does become noise over time so I would even consider dropping the mention of jitter for test tone noise measurements if the FFT sample count is increased. Normalizing all test tones (not J-Test) to 12kHz seems arbitrary as well and might lead to others comparing test tone spectrum with jitter. A twin tone test would likely be better but that's another topic : )

One other thought is that a 50/60/100/120Hz mains component should be clearly visible on the noise but probably not in a low FFT sample J-Test. Using a low FFT sample may mask this.
 
Joined
Sep 13, 2018
Messages
8
Likes
6
#65
So my question is, if we use an Android app designed to work with the CCA and use the toslink out do we get the first [bad] or second [good] result?

If you don't already have Roon, the cost of it to use the CCA effectively is a real deal killer. If instead I can get the CCA for $35, and use a music app that costs less than $10, getting the same quality result then we may be onto something.
These are my thoughts exactly....thank you Blumlein!

Amir: Any chance you can do a quick test using an Android app such as Hi-Fi Cast, BubbleUPnP, Media Monkey or any of the others mentioned by Blumlein?
 

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
15,369
Likes
9,362
Location
Seattle Area
#66
Hi Amir, thanks again for offering up the measurements on such a widely used device. It's often recommended on reddit so it's nice to see that it performs well.

Regarding the mentions of jitter here and in other reviews, I have some concern of how they might be interpreted. Using a single visualization to show jitter and noise spectra seems to mix the testing intents. Measuring clock jitter and noise should be treated separately so I would expect to see a true J-Test (with LSB toggle at Fs/4) for jitter but use a higher FFT sample to capture noise. Jitter does become noise over time so I would even consider dropping the mention of jitter for test tone noise measurements if the FFT sample count is increased. Normalizing all test tones (not J-Test) to 12kHz seems arbitrary as well and might lead to others comparing test tone spectrum with jitter. A twin tone test would likely be better but that's another topic : )

One other thought is that a 50/60/100/120Hz mains component should be clearly visible on the noise but probably not in a low FFT sample J-Test. Using a low FFT sample may mask this.
Hi there. The FFTs I am showing have 256K points so very high resolution. There is unfortunately no way to untangle noise, distortion, jitter and Vref modulation in this analysis. All of them show up concurrently. Only further analysis will determine if some are jitter versus something else. Others performing this measurement say it is "jitter" when in reality it is all of those and hence the reason I label them that way.

The test tracks are normally J-test. Here, I didn't have the 44.1 kHz 16 bit handy so used a simple tone.
 

gvl

Addicted to Fun and Learning
Joined
Mar 16, 2018
Messages
560
Likes
180
Location
SoCal
#67
These are my thoughts exactly....thank you Blumlein!

Amir: Any chance you can do a quick test using an Android app such as Hi-Fi Cast, BubbleUPnP, Media Monkey or any of the others mentioned by Blumlein?
Probably best to use a flac compressed test tone file as well as no one typically streams uncompressed WAV to CCA.
 

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
15,369
Likes
9,362
Location
Seattle Area
#68
Yes. The test file was 16 bits, 44100 kHz.
Oops. This was incorrect. I was testing 48 kHz. Fortunately it makes no difference what the sample rate is. Here is the digital spectrum with 44.1 kHz sampling and Flac file format to answer the other question:

1536870944569.png


So just as bad.....
 

gvl

Addicted to Fun and Learning
Joined
Mar 16, 2018
Messages
560
Likes
180
Location
SoCal
#69
It is puzzling as to why would Chrome decompress a flac file to compress it again to who knows what... Perhaps for volume control? CCA has onboard volume control. Odd.
 

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
15,369
Likes
9,362
Location
Seattle Area
#70
Amir: Any chance you can do a quick test using an Android app such as Hi-Fi Cast, BubbleUPnP, Media Monkey or any of the others mentioned by Blumlein?
Good suggestion and success!

Google Chromecast Audio Toslink through hi-fi cast Android app Measurement.png


So seems like the API google gives to developers is correct. Just that their implementation in Chrome browser is broken.
 

Soniclife

Addicted to Fun and Learning
Joined
Apr 13, 2017
Messages
690
Likes
276
Location
UK
#71
Good suggestion and success!

View attachment 15641

So seems like the API google gives to developers is correct. Just that their implementation in Chrome browser is broken.
Which app was that with?

My guess is the browser is configured for maximum stability and flexibility, at the expense of fidelity. They probably prioritised the video version as well.
 

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
15,369
Likes
9,362
Location
Seattle Area
#72
Tried playing the test files in Android Google music player and it keeps complaining that I need to use a PC music app to upload the file??? I side-loaded the files into the phone so they are sitting there ready to play and it won't cast them to chromecast. :( It plays them locally however.
 

Soniclife

Addicted to Fun and Learning
Joined
Apr 13, 2017
Messages
690
Likes
276
Location
UK
#73
Oops. This was incorrect. I was testing 48 kHz. Fortunately it makes no difference what the sample rate is. Here is the digital spectrum with 44.1 kHz sampling and Flac file format to answer the other question:

View attachment 15640

So just as bad.....
Is that sort of result consistent with it going through a lossy step?
 

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
15,369
Likes
9,362
Location
Seattle Area
#74

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
15,369
Likes
9,362
Location
Seattle Area
#75
Is that sort of result consistent with it going through a lossy step?
Every lossy compression is different so there is no complete answer. But yes, based on amount of transformation that has occurred, my guess continues to be some kind of lossy compression being applied. Or at least a lot of processing.

Here is a digital test of 1 kHz tone at 0 dBFS through Chrome browser:
1536872928549.png


Note that it is clipped due to amplitude being risen to +0.272 dBFS.

Here is the same file played through Roon:

1536873138097.png


Notice no clipping.

FYI all my test files in the review were at -1 dBFS so the above is not at issue. There is a serious transform occurring on the file when using Chrome browser.
 

Soniclife

Addicted to Fun and Learning
Joined
Apr 13, 2017
Messages
690
Likes
276
Location
UK
#77
Every lossy compression is different so there is no complete answer. But yes, based on amount of transformation that has occurred, my guess continues to be some kind of lossy compression being applied. Or at least a lot of processing.

Here is a digital test of 1 kHz tone at 0 dBFS through Chrome browser:
View attachment 15642

Note that it is clipped due to amplitude being risen to +0.272 dBFS.

Here is the same file played through Roon:

View attachment 15643

Notice no clipping.

FYI all my test files in the review were at -1 dBFS so the above is not at issue. There is a serious transform occurring on the file when using Chrome browser.
Thanks, I think I'd be surprised if Chrome wasn't re-encoding the audio.

So if looks like the device itself is very good, but it is obviously at the mercy of what it is sent, or more accurately what it is told to stream.
 

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
15,369
Likes
9,362
Location
Seattle Area
#78
Joined
Aug 4, 2018
Messages
22
Likes
8
#79
Thx Amir, again. I love my CCA (youtube RED subscription works for a 6 member family for $15/mo). Google just needs to put more 24/96. Thats enough hi-res for me
 
Joined
Jun 26, 2018
Messages
13
Likes
1
#80
Tidal (both desktop and iOS apps) supports Chromecast streaming directly. What if you cast to the Chromecast audio using Tidal directly? It'd be interesting to see those results because that's how I do it! :)
 
Top Bottom