• 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

gvl

Major Contributor
Joined
Mar 16, 2018
Messages
3,427
Likes
3,982
Location
SoCal
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

Grand Contributor
Forum Donor
Joined
Feb 23, 2016
Messages
20,524
Likes
37,057
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.
index.php

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.

index.php


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

Major Contributor
Joined
Mar 16, 2018
Messages
3,427
Likes
3,982
Location
SoCal
^^^ 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:

Umlautica

Member
Joined
Jul 25, 2018
Messages
18
Likes
40
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
70
Likes
79
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?
 
OP
amirm

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
44,376
Likes
234,548
Location
Seattle Area
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

Major Contributor
Joined
Mar 16, 2018
Messages
3,427
Likes
3,982
Location
SoCal
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.
 
OP
amirm

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
44,376
Likes
234,548
Location
Seattle Area
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

Major Contributor
Joined
Mar 16, 2018
Messages
3,427
Likes
3,982
Location
SoCal
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.
 
OP
amirm

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
44,376
Likes
234,548
Location
Seattle Area
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

Major Contributor
Forum Donor
Joined
Apr 13, 2017
Messages
4,500
Likes
5,417
Location
UK
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.
 
OP
amirm

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
44,376
Likes
234,548
Location
Seattle Area
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

Major Contributor
Forum Donor
Joined
Apr 13, 2017
Messages
4,500
Likes
5,417
Location
UK
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?
 
OP
amirm

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
44,376
Likes
234,548
Location
Seattle Area
OP
amirm

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
44,376
Likes
234,548
Location
Seattle Area
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

Major Contributor
Forum Donor
Joined
Apr 13, 2017
Messages
4,500
Likes
5,417
Location
UK
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.
 
OP
amirm

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
44,376
Likes
234,548
Location
Seattle Area

envydd

Active Member
Forum Donor
Joined
Aug 4, 2018
Messages
101
Likes
55
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
 

tensor9

Active Member
Forum Donor
Joined
Jun 26, 2018
Messages
149
Likes
90
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