[GoldenSound]

There is no better clock for the CM4 module and / or its USB output interface,

There is no need for an upgraded clock because the output jitter is determined by the ddc/output. The data is passed from the pi to the ddc section asynchronously.

I'm also not sure that the pi/cm4 can even accept an external clock even if you did for some reason want to use one.

As for USB, USB does not have jitter in the same way as spdif/i2s. There is no clock signal provided or used by the recipient device for conversion like a word clock is on spdif or i2s.
It is put into a buffer and then output using the clocks in the recipient device. This applies to both DACs and DDCs.

It does have separate filtering/power for the USB out though. Its not just running off the pi itself

 

[tomita]

There is no need for an upgraded clock because the output jitter is determined by the ddc/output. The data is passed from the pi to the ddc section asynchronously.

I'm also not sure that the pi/cm4 can even accept an external clock even if you did for some reason want to use one.

As for USB, USB does not have jitter in the same way as spdif/i2s. There is no clock signal provided or used by the recipient device for conversion like a word clock is on spdif or i2s.
It is put into a buffer and then output using the clocks in the recipient device. This applies to both DACs and DDCs.

It does have separate filtering/power for the USB out though. Its not just running off the pi itself

There is no need for an upgraded clock because the output jitter is determined by the ddc/output. The data is passed from the pi to the ddc section asynchronously.

I'm also not sure that the pi/cm4 can even accept an external clock even if you did for some reason want to use one.

As for USB, USB does not have jitter in the same way as spdif/i2s. There is no clock signal provided or used by the recipient device for conversion like a word clock is on spdif or i2s.
It is put into a buffer and then output using the clocks in the recipient device. This applies to both DACs and DDCs.

It does have separate filtering/power for the USB out though. Its not just running off the pi itself

So, in terms of USB out SQ, the only benefit of this streamer over others (eg: Allo's USB signature) is the power supply?

 

[GoldenSound]

So, in terms of USB out SQ, the only benefit of this streamer over others (eg: Allo's USB signature) is the power supply?

It's a bit of a loaded question. The only thing that actually makes a difference with USB (in terms of the source) is noise.
Which this addresses and like the zen stream for example will have a very low noise output.

As mentioned, USB audio is asynchronous. The recipient device does not utilise a clock signal from the source for audio and so having a high performance clock specifically for the USB controller would just be adding cost for no reason.

They've not included stuff which makes no sense to include.

 

[tomita]

It's a bit of a loaded question. The only thing that actually makes a difference with USB (in terms of the source) is noise.
Which this addresses and like the zen stream for example will have a very low noise output.

As mentioned, USB audio is asynchronous. The recipient device does not utilise a clock signal from the source for audio and so having a high performance clock specifically for the USB controller would just be adding cost for no reason.

They've not included stuff which makes no sense to include.

Totally agree. I'll never understand gear like Innuos's Phoenix USB Reclocker. However, I'm interested to find out what exactly is the Red streamer doing to eliminate any noise coming from the cm4.
You said that the data is passed from the cm4 to the Red. Is there any isolation that prevents noise also traveling from one part to another?

 

[roderickvd]

While I totally support the asynchronous USB argument, I find it interesting that one of the defining features of the "PRO" edition of the Singxer SDA-6 is that it has a Crystek 957 as a USB clock. Other USB modules like IanCanada's and JLSound's also support external master clock input. USB *does* need a clock (48 MHz for full-speed USB 2.0), separate from the "DAC clock" we normally talk about, but whether the quality of the USB clock is audible after buffering? Loaded indeed.

 

[GoldenSound]

While I totally support the asynchronous USB argument, I find it interesting that one of the defining features of the "PRO" edition of the Singxer SDA-6 is that it has a Crystek 957 as a USB clock

This is a different situation. The DAC is the recipient device and the Crystek 957 clocks inside the SDA-6 are used to control the DAC itself and therefore have a direct impact on performance. This is not the same as a clock on a USB output.

The clocks in a DAC absolutely matter.

Other USB modules like IanCanada's and JLSound's also support external master clock input

There are plenty of products in audio that have various features and design aspects. But inclusion of something in some products does not mean it's actually beneficial to do.

USB *does* need a clock (48 MHz for full-speed USB 2.0), separate from the "DAC clock" we normally talk about

USB does run at a speed of 48Mhz, but the point is that this clock is not used at all for the actual audio conversion.
Everything is put into a buffer, and then converted using the DAC's internal clocks (such as the Crystek 957s in the aforementioned SDA-6). So long as this clock is not so terrible that the devices are unable to communicate properly or there is a buffer underrun (buffer becoming empty due to not being fed info fast enough) or a buffer overrun (buffer becoming full), it does not have an effect on DAC performance. (You'll know if you have either of these issues as the connection will either fail completely or you'll get very obvious clicking/popping sounds.

If this were the case, then a huge amount of modern USB or network based devices and technologies simply wouldn't work.

but whether the quality of the USB clock is audible after buffering?

As mentioned, if this were the case, it would completely defy our understanding and design of many modern communications technologies and they simply would not work.
Showing a difference in jitter due to different SPDIF, I2S or other synchronous protocol sources is easy. In fact it's pretty easy to even show (very small) differences due to different cables.
But with USB, no evidence has ever been shown that the clock of the USB controller in the host device could have an impact on jitter of the converter. Nor any explanation as to how that could be the case.

(UAC1.0 is a different discussion but basically nothing uses that nowadays so it's a bit of a moot point)

 

[roderickvd]

This is a different situation. The DAC is the recipient device and the Crystek 957 clocks inside the SDA-6 are used to control the DAC itself and therefore have a direct impact on performance. This is not the same as a clock on a USB output.

The clocks in a DAC absolutely matter.

There are plenty of products in audio that have various features and design aspects. But inclusion of something in some products does not mean it's actually beneficial to do.

Absolutely. Yet when they come from reputable sources, we may at least give it some thought right? As we are doing now. Thanks for your reply. There are many vendors and products that contain snake oil, yet this would be a first for Singxer. I don't find that impossible, just interesting.

USB does run at a speed of 48Mhz, but the point is that this clock is not used at all for the actual audio conversion.

Everything is put into a buffer, and then converted using the DAC's internal clocks (such as the Crystek 957s in the aforementioned SDA-6).

To be totally clear the Crystek in this unit is on the transceiver side of the XMOS processor. In this reference design, the 13 MHz oscillator on the top left. The "DAC clocks" in the SDA-6 are non-Crystek OXCO's, in the figure the "Audio Master Clock Oscillator" on the bottom right.

This is just the reference design, so assume the DAC or any other transport where it says "CS4270".

This 13 MHz oscillator on the transceiver side is what I meant when I said "not the DAC clock" but "the USB clock".
Just checking if that's also what you mean?

So long as this clock is not so terrible that the devices are unable to communicate properly or there is a buffer underrun (buffer becoming empty due to not being fed info fast enough) or a buffer overrun (buffer becoming full), it does not have an effect on DAC performance. (You'll know if you have either of these issues as the connection will either fail completely or you'll get very obvious clicking/popping sounds.

If this were the case, then a huge amount of modern USB or network based devices and technologies simply wouldn't work.

Yeah. And the USB jitter spec is such that we don't need femto-clocks at all for the transceiver:

But with USB, no evidence has ever been shown that the clock of the USB controller in the host device could have an impact on jitter of the converter. Nor any explanation as to how that could be the case.

Hence my interest why a reputable vendor like Singxer stuck in a Crystek there anyway. Interesting, right, or just folly?

Back on topic, I also believe that reclocking is useless for asynchronous USB, but here I am testing my beliefs.

 

[GoldenSound]

There are many vendors and products that contain snake oil, yet this would be a first for Singxer. I don't find that impossible, just interesting.

To be totally clear the Crystek in this unit is on the transceiver side of the XMOS processor. In this reference design, the 13 MHz oscillator on the top left. The "DAC clocks" in the SDA-6 are non-Crystek OXCO's, in the figure the "Audio Master Clock Oscillator" on the bottom right.

I think the main issue here is a slight misunderstanding of the way the USB interface works.
The clocks here are indeed also being fed to the XMOS chip, though this is the same in the vast majority of DACs. This isn't actually Singxer doing any sort of snakeoil. That connection is necessary for the XMOS chip to function in its role.

The XMOS chip/USB receiver is communicating with two things, the USB host (PC), and the DAC.
It needs the DAC internal clock to know when to actually output the data to the DAC. It cannot do this independently without a clock signal. But this is not a replacement/substitute for the USB Host <-> XMOS connection which runs at 48Mhz no matter what. The two sides are running at different rates all the time.
You can be playing at 44.1khz (and therefore using the 11.289Mhz clock) or 48khz (and therefore using the 24.576Mhz clock), but the USB connection is still running at 48Mhz no matter what. The primary job of the XMOS chip is to serve as a buffer and translation layer of sorts, taking the incoming data, buffering, and outputting in I2S format to the DAC itself at the correct rate, independent of and unrelated to the USB connection clock speed.

The clock being connected to the XMOS chip is standard operating procedure for DACs. Though some will instead have more basic clocks connected to it, then attenuate jitter using a PLL on the DAC chip itself (as many modern chips have this built in) with the primary clocks.

 

[brianfromspace]

This friday Hans v Beekhuyzen will share his thoughts on his YT channel I’ve heared through the grapevine. Excited, just cause of my interest in HQ player nowadays I would be willing to invest in this red box. The Pi2AES is limited to 192khz so no upsampling to the moon and back. Still best audio investment that transparent box.

Correction he has the Magna Hifi new Mano streamer with Farad LPS, NOT the Red. That was still not to be listened to at Magna.

 

[roderickvd]

I think the main issue here is a slight misunderstanding of the way the USB interface works.

You can be playing at 44.1khz (and therefore using the 11.289Mhz clock) or 48khz (and therefore using the 24.576Mhz clock), but the USB connection is still running at 48Mhz no matter what. The primary job of the XMOS chip is to serve as a buffer and translation layer of sorts, taking the incoming data, buffering, and outputting in I2S format to the DAC itself at the correct rate, independent of and unrelated to the USB connection clock speed.

I fully understand. But I do think we are not fully on the same wavelength yet

The clock being connected to the XMOS chip is standard operating procedure for DACs. Though some will instead have more basic clocks connected to it, then attenuate jitter using a PLL on the DAC chip itself (as many modern chips have this built in) with the primary clocks.

When you say "the clock being connected to the XMOS chip", which clock are you referring to?

 

[GoldenSound]

I fully understand. But I do think we are not fully on the same wavelength yet

When you say "the clock being connected to the XMOS chip", which clock are you referring to?

Ah sorry, didn`t see that bit at the top left. I was referring to the bottom right word clocks feeding both the DAC and XMOS chip.
The other oscillator referred to in the top left of that diagram isn`t a particularly fancy one.
I`m not sure what manufacturer it is, but it`s certainly not a 957.

You can see it on the board here

For comparison, the main clocks are under the big white box in the centre, and the 957 units themselves look like this, and are substantially bigger than the one on the USB area of the PCB:

 

[roderickvd]

Good point. Thanks! I wonder what the Singxer marketing blurb is about then... Crysteks under the hood of the oven?
Oh well, not to stray off-topic, I'll take that up on the dedicated SDA-6 thread.

The clock on the Red won't matter for asynchronous USB

 

[GoldenSound]

Good point. Thanks! I wonder what the Singxer marketing blurb is about then... Crysteks under the hood of the oven?
Oh well, not to stray off-topic, I'll take that up on the dedicated SDA-6 thread.

The clock on the Red won't matter for asynchronous USB

I'd assume that's in reference to the main clocks.

Singxer has an oven for temperature control but the crystek clocks are under it. They're doing a similar thing in the SU6 DDC.

 

[chipvn]

There is no need for an upgraded clock because the output jitter is determined by the ddc/output. The data is passed from the pi to the ddc section asynchronously.

I'm also not sure that the pi/cm4 can even accept an external clock even if you did for some reason want to use one.

As for USB, USB does not have jitter in the same way as spdif/i2s. There is no clock signal provided or used by the recipient device for conversion like a word clock is on spdif or i2s.
It is put into a buffer and then output using the clocks in the recipient device. This applies to both DACs and DDCs.

It does have separate filtering/power for the USB out though. Its not just running off the pi itself

I understand how USB works comparing to SPDIF/I2S. Techically, I also don't think we need any special device as streaming endpoint (if using Roon Bridge or HQPlayer NAA) with USB output if the downstream DAC have good design USB interface. However, as an hobby, I still try to get as fancy device as possible.

For example if using as HQPlayer NAA function, from the board configuration, I assume that the data flow from Ethernet port in to the CM4 via its built-in interface to the FIFO buffer then later go out from the CM4 to the USB output port via the CM4 built-in USB2 interface. In this case, the operation of all componens on the CM4 (included the USB2 interface) depend on 2 standard tiny clocks at the back of the CM4 module. While the asynchronous USB don't need very fancy clock, it is still better to have a good upgraded one. If not, for NAA streaming function with USB out, the Red might work similar to a standard Pi CM4 carrier board with an external LPS.

For Holo (May or Spring) users like me, if we agreed 100% on asynchronous USB, then any power enough device with USB output port should work the same, cause data will be buffered at the DAC USB interface. Any noise carried over via USB will be isolated by the Galvanic Isolators after the USB input section of the Holo DAC.
For current Holo (May or Spring) users want to get Red to use as I2S interface with May or Spring, it is worth to reconsider cause the DDC section of the Red might not be as good as the built-in one with much superior FEMTO clocks inside the May or Spring DAC.

 

[bfin3]

I've been very interested in switching over to holo devices and the red could fit very well into my digital chain so it's made it that much more enticing. Right now for games/movies I've got a gaming pc into an su-2 KTE and for music a Innuos zenith mk3. I downloaded hqplayer to test some things out. Innuos can now be a hqplayer NAA so I tried it out that way with my gaming pc being an hqplayer server. The pc as a standalone hqplayer output sounds about the same as using it with the innuos as an endpoint. Using the zenith with it's native software sounds significantly better than either though. Is it possible that I'm missing out on settings, or is a source pc that isn't optimized for audio going to hold it back?