Streamers with Chromecast?

[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.

 

[miguelito]

6 minutes ago, Miska said:

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

I have a license for HQP desktop 3. Maybe I would bring it in the mac’s optical, then somehow have HQP pick it up from there and route it to USB?

 

Is HQP somehow buffering/reclocking the SPDIF from toslink?

 

Can you explain how to set this up please?

[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.

 

[asdf1000]

4 hours ago, Miska said:

 

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.

 

 

But @miguelito was really convinced the optical output jitter is a serious problem with his Rossini.

 

Perhaps you can explain how this is a non-issue for HQPlayer...

 

Perhaps it may be a non-issue for some DACs in similar way too...

[Rexp]

7 hours ago, Miska said:

 

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

If you think lossless formats like redbook are so great, why bother with Hqplayer? 

[miguelito]

8 hours ago, Miska said:

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.

Ok... Questions:

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

2- Do you buffer and reclock?

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? 

 

Sorry... Not an expert, but certainly curious.

[asdf1000]

2 hours ago, miguelito said:

Sorry... Not an expert, but certainly curious.

 

Not an expert? In this thread you wrote:

 

On 10/11/2019 at 12:58 PM, miguelito said:

 

People really need to understand what “jitter”, “SPDIF”, etc. means. Jeez.

 

 

That sounds like the tone of an expert.

[audiobomber]

Deleted.

[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.

 

[miguelito]

17 minutes ago, Miska said:

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.

Thx. Understood on the clock bit since it's USB or NAA out. When the SPDIF stream starts coming in, you're probably filling a buffer - how long is that roughly? I imagine that in practice it probably works like the Audirvana mem caching delay.

 

If I run SPDIF in (via toslink) and I bridge to a USB DAC, I wonder if it would work without any additional software (other than soundflower to bridge the two together for example). What I wonder is if OSX would create the buffer itself.

[miguelito]

3 hours ago, miguelito said:

If I run SPDIF in (via toslink) and I bridge to a USB DAC, I wonder if it would work without any additional software (other than soundflower to bridge the two together for example). What I wonder is if OSX would create the buffer itself.

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.

[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.

 

[miguelito]

@mansr and @Miska... I have a few questions that I think you’d be able to clarify...

 

Question 1 - Clock recovery vs buffering/reclocking

I understand that buffering and reclocking (or not reclocking in the case of putting the signal up for USB transmition - though at some point a second clock does come in) is tricky as there’s no way to control the source in the SPDIF case. Since the two clocks (source and reclocking) will be different, either the buffer runs out or gets too full. 

 

However, I have tried the following: take the signal from a ChromecastAudio dongle via Toslink into my dCS Rossini, and set the Rossini to use the dCS Rossini master clock (thus not recovering the clock from the SPDIF signal but instead using the clock from the master clock). I have played this for hours and I have not experienced a glitch at all. This somehow contradicts the fact that we have two clocks, one will go faster than the other necessarily, and thus either a buffer runs out or gets full and the sound stops. 

 

My hunch is what is happening is that, if the distribution of time from the source is wide enough and the distribution of time from the reference clock (likely much narrower) is within the source’s wide distribution, even though the means don’t match, there is a continuous catching up from the source as the time distributions are overlapping. At the end of the day, a ‘1’  is a signal that transitions from one state to the next somewhere within the sample interval, not necessarily in the middle. 

 

Does this make sense?

 

Question 2: Why is I2S any better than SPDIF?

My understanding is I2S has a separate clock line. However, since SPDIF has a transition on EVERY cycle, there isn’t really any more info in the I2S signal vs the SPDIF signal. So why would I2S be any better?

 

Thank you!

[Ralf11]

On 10/10/2019 at 6:57 PM, miguelito said:

I am. I want ChromecastAudio to stream things like SoundCloud, Mixcloud, etc to the Rossini as cleanly as possible.

 

Do you have to use Chromecast?

 

I am getting cognitive dissonance just thinking about it in your system...

[miguelito]

Just now, Ralf11 said:

Do you have to use Chromecast?

 

I am getting cognitive dissonance just thinking about it in your system...

That’s cute.

 

How else would I play Soundcloud or Mixcloud from the convenience of my phone/ipad? One way that involves having the device in the loop is of course Airplay.

[Ralf11]

I dunno - maybe it is possible to use the iPad as a controller, rather than a source?

 

I use AirPlay myself and it is just fine on Redbook.  OTOH, a lot of the listening I do is non-Classical (non-Baroque, etc. etc.) and involves early jazz, blues... so the source isn't exactly highest SQ.

[miguelito]

1 minute ago, Ralf11 said:

I dunno - maybe it is possible to use the iPad as a controller, rather than a source?

That’s exactly what the ChromecastAudio protocol does - very similar to Spotify Connect.

 

1 minute ago, Ralf11 said:

I use AirPlay myself and it is just fine on Redbook.  OTOH, a lot of the listening I do is non-Classical (non-Baroque, etc. etc.) and involves early jazz, blues... so the source isn't exactly highest SQ.

Airplay would be perfect as Soundcloud does not sound even close to redbook. The catch is the playing device is in the loop at all times. I listen to electronica/techno/house/etc when listening to Soundcloud/Mixcloud.

[mansr]

1 hour ago, miguelito said:

Question 1 - Clock recovery vs buffering/reclocking

I understand that buffering and reclocking (or not reclocking in the case of putting the signal up for USB transmition - though at some point a second clock does come in) is tricky as there’s no way to control the source in the SPDIF case. Since the two clocks (source and reclocking) will be different, either the buffer runs out or gets too full. 

 

However, I have tried the following: take the signal from a ChromecastAudio dongle via Toslink into my dCS Rossini, and set the Rossini to use the dCS Rossini master clock (thus not recovering the clock from the SPDIF signal but instead using the clock from the master clock). I have played this for hours and I have not experienced a glitch at all. This somehow contradicts the fact that we have two clocks, one will go faster than the other necessarily, and thus either a buffer runs out or gets full and the sound stops. 

 

My hunch is what is happening is that, if the distribution of time from the source is wide enough and the distribution of time from the reference clock (likely much narrower) is within the source’s wide distribution, even though the means don’t match, there is a continuous catching up from the source as the time distributions are overlapping. At the end of the day, a ‘1’  is a signal that transitions from one state to the next somewhere within the sample interval, not necessarily in the middle. 

 

Does this make sense?

If you force the use of a local clock, there will inevitably be occasional slippage. When this happens, the most likely result is that a sample is dropped or repeated which may not be obviously audible. I'm sorry, but your idea doesn't quite work out.

 

1 hour ago, miguelito said:

Question 2: Why is I2S any better than SPDIF?

My understanding is I2S has a separate clock line. However, since SPDIF has a transition on EVERY cycle, there isn’t really any more info in the I2S signal vs the SPDIF signal. So why would I2S be any better?

Yes, why indeed?

[miguelito]

6 minutes ago, mansr said:

If you force the use of a local clock, there will inevitably be occasional slippage. When this happens, the most likely result is that a sample is dropped or repeated which may not be obviously audible. I'm sorry, but your idea doesn't quite work out.

Ok, agreed... Thank you.

 

6 minutes ago, mansr said:

Yes, why indeed?

Are you saying this tongue in cheek or are you puzzled like I am?

[mansr]

8 minutes ago, miguelito said:

Are you saying this tongue in cheek or are you puzzled like I am?

An I2S signal can be fed directly into a DAC chip, which is presumably what appeals to some. However, the cable, connectors, and transceivers all expose the signal to noise and reflections, which can cause jitter etc. This can be mitigated by cleaning the clock with a PLL, but then you might as well just use S/PDIF.

[Ralf11]

Let's back out and look at this another way...

 

is there any other source of the electronica/techno/house/etc. you want to listen to?

[miguelito]

1 hour ago, Ralf11 said:

Let's back out and look at this another way...

 

is there any other source of the electronica/techno/house/etc. you want to listen to?

Plenty! But there are these long mixes on Soundcloud that are unbeatable, and only available there.

 

For example:

 

I am a "music first audiophile"!!!

[Ralf11]

I wonder what would happen if you sent an Email to Jeff Bezos about the topic of high SQ sound-casting?  You could mention the looming market opportunities and how many round lots of AMZN you hold...