Streamers with Chromecast?

[Miska]

48 minutes ago, miguelito said:

Google discontinued the ChromecastAudio dongle, but has not abandoned Chromecast. There are a host of solutions coming out (eg a new Cambridge streamer, Primare's NP5, etc) that incorporate Chromecast inside. This looks to be the code implemented:

 

https://support.google.com/chromecastbuiltin/answer/6121012?hl=en

 

Any devices I can plug a USB DAC into that support this? Something like a microRendu would be ideal.

 

I guess that's the (L)GPL licensed code they've used in the firmware and not Chromecast implementation...

 

[Miska]

48 minutes ago, miguelito said:

Ok, I am not an expert here, but I can see that Google has not abandoned Chromecast - as there are many new implementations as I mentioned -  but it is unclear to me whether the code is under an open source license and can be used by anyone who wishes to. Like I said I am not an expert but it is at least reasonable to assume that if the NP5 can implement it so can other similar devices.

 

AFAIK, it is fairly easy to get API keys to send audio to a Chromecast device. But to implement a Chromecast device you need custom hardware with DRM facilities, and for that you need to have a special deal with Google.

 

[Miska]

On 10/11/2019 at 2:40 AM, miguelito said:

I do have a ChromecastAudio dongle, connected over toslink to my Rossini. Sound is NOT great.

 

I have Chromecast Audio dongle, connected over Toslink to HQPlayer, and no complaints about the sound...

 

[Miska]

13 hours ago, Rexp said:

For point and play convenience you can get a bluetooth receiver with optical out like this, SQ should be on par with spotify connect. 

http://www.the-ear.net/news/bluetooth-attains-enlightenment

 

Spotify + Bluetooth = two cascaded lossy codecs = really bad sound

[Miska]

On 10/11/2019 at 3:04 PM, miguelito said:

So are you saying that all these devices have a chip that allows them to be a ChromecastAudio endpoint - ie not implemented in software?

 

Yes... I think it is largely similar with the ones that have official Airplay.

 

[Miska]

Just now, miguelito said:

Ok can you explain how that works?

 

HQPlayer v4 supports realtime inputs from audio devices. So I have things like RME ADI-2 Pro where I have AES input from my Mac Mini and Toslink input from Chromecast audio, coaxial will be from Bluesound Node2i in future and analog is analog tape output from my pre-amp. I have also HQPlayer Embedded machine with miniDSP USBStreamer with Toslink input from another Chromecast Audio. When I want to play such sources, I just select relevant input in HQPlayer. Output is DSD256 to the DAC, regardless of the source format.

 

[Miska]

17 hours ago, miguelito said:

1- Why does it improve SPDIF (toslink or otherwise)?

 

17 hours ago, miguelito said:

2- Do you buffer and reclock?

 

17 hours ago, miguelito said:

3- If you buffer and reclock, how do you ensure that your buffer is never too full or too shallow? Do you make sure to run the clock slower than the input?

 

I don't run any clocks anywhere, CPU/GPU/RAM and data buses of course run at their own clocks, completely asynchronously from any audio. Buffers are large enough that the sample rate would need to be grossly off for buffers to over- or underflow regularly. If it happens, you have a honest noticeable gap in the sound.

 

[Miska]

7 hours ago, miguelito said:

This actually works - I used RogueAmoeba's Audio Hijack to route the digital in to the USB DAC out. And it sounds pretty good. However, I would like to find a more lightweight way to do the routing.

 

You can do all the DSP while doing it, so why not? My HQPlayer Embedded box is my "upsampler", just happens to also have digital room correction and other stuff too. In addition it happens to work with Roon and UPnP. Headless box that comes up and goes down with a press of power button.

 

I don't need Chromecast audio dongle for anything else than Spotify use. Tidal goes through UPnP.

 

[Miska]

On 10/11/2019 at 5:13 AM, miguelito said:

Jitter from the Chromecast dongle is exactly the problem. If you read my description above you’ll see it is not really possible to correct a bad clock using an SPDIF interface. The rate is not a limitation.

 

No I don’t think it’s Rossini. Toslink out of the Chromecast dongle sounds bad with every DAC, assuming you have a decent enough system to tell the difference.

 

I'm feeding it to HQPlayer and I can't say it sounds bad. And it can't be about clocking since the clock is not really used.

 

If it sounds bad and you have full reclocking, then it is certainly something other than the clock.

 

[Miska]

9 hours ago, miguelito said:

However, the perennial question: How can you a make a separate clock work reliably without issues? Should not be possible! The two clocks are running at different rates. So if the source clock is slower the buffer runs out, and if it is faster it will overflow.

 

If the rate error is small enough it takes long enough. I don't know how dCS handles this, but with HQPlayer you get a clear gap. So far I haven't got endurance to listen long enough for it to happen.

 

[Miska]

23 minutes ago, Richard Dale said:

Is the clock sync for the S/PDIF transfer reset at the start of each track?

 

No, at rate change or when playback is started...

 

[Miska]

9 hours ago, miguelito said:

Understood. It is a funny answer though, because it is technically better in the sense it will sound better as long as it doesn't reach the point where there's a gap in sound.

 

dCS uses a double-cable SPDIF (AES) connection between separates, but they also use a master clock orchestrating all the signals, so issues with clock recovery are not present.

 

Interestingly, I2S separates data and clock signal. However, since SPDIF spec has a transition on every clock cycle (a 0 is a "no transition" between clock cycles while a 1 is a "transition" between the cycles), then I frankly don't see why I2S is any better than standard SPDIF... In the dCS case it is because the clock master comes from a precise stable clock box rather than the source component. In I2S, you're slaved to the source essentially, so your jitter will be at least the one in the source.

 

Problem with external clocks is usually that they run at fixed frequency, 10 MHz seems like being most common. Which means that the actual clocks need to be generated from it using a PLL. Which in turn is not any better than for example clock recovery from S/PDIF or similar.

 

Also word clock sources suffer from the same problem, even though they must be sending correct family clock, but the clock frequency is too low and again needs a PLL to generate the actual tens of MHz range clocks.

 

Otherwise there needs to exist mechanism where the source component can switch the clock frequency between the 44.1k and 48k families and the clock needs to be something like 22.5792/24.576 MHz... I don't remember seeing such in practice.

 

Thus I rather stick to a local master clock. Also allows me to do things like taking input at 44.1k and having output at 192-family rate such as 768k. Without resorting to an ASRC.

 

[Miska]

2 hours ago, miguelito said:

dCS master clocks generate two sources separately for the 44.1 and 48 families, and in fact there are two cables to the component that determines which to pick (in my case the Rossini DAC).

 

But it is still a word clock at the sample rate, so it needs to go through PLL at the DAC...