RAAT and clock ownership

[brian (Brian Luczkiewicz)]

@Antonio_Bendezu

From re-reading this thread for, like, the third time, it seems that @brian’s statement is only true if the DAC is connected via USB to the network audio adapter (microrendu, squeezebox, raspberry pi, PC, etc.), or if the DAC is married to the network audio adapter in the same device, such as the network DAC he uses as an example. That is because, as I understand it, the Roon endpoint has access to the DAC’s clock info.

RAAT never runs in a source-clocked mode–it is always locked against something, which in practice is the furthest clock in the chain that we can get access to. This is most often the DAC’s clock. Next most often, it’s the clock in an S/PDIF, AES, or UAC1.0 interface.

@Antonio_Bendezu

It seems like @gasman’s question remains unanswered, unless the answer already given amounts to: “maybe, but only if those auxiliary devices give Roon access to the modified/new DAC clock signal.” Is that a fair summary, @brian?

This summary is an example of the exact kind of confusion that I was warning against above.

If you think through the implementation details of these devices (if you haven’t, read and fully digest John Swenson’s link that I posted above, which explains one such product and provides a good framework for further understanding), it’s clear that these devices are proxying USB packets at a low level and not the USB Audio Protocol itself.

This means there is no “giving access” or “interfering” to consider. Roon is seeing the DAC’s clock through these devices, just as it would through any other USB hub.

To be 100% clear: the reclocking done in these kinds of devices has nothing to do with the audio clock. They are reclocking USB data transmission bits in layer that is not synchronously coupled to audio playback or the audio sample clock.

@Antonio_Bendezu

I think that’s what @gasman’s question was getting at: will Roon’s use of the DAC’s clock signal to pull the audio stream to the network audio adapter ignore the separate clocks or other USB enhancements? Since the answer seems like it might be “maybe,” perhaps you guys could point to some such “enhancement” products that are able to deliver the enhanced clock signal for Roon to use as the reference clock? Perhaps specific features/technology to look for in such products that would help us determine whether they are being ignored by Roon?

The reason why @gasman’s question is not getting a clear answer is because it used the word “clock” in a more imprecise way than in my original statement which he was referencing, and this created an ambiguity. I was talking about sample clocks, which are not the domain of these USB enhancer products.

This is why I went about explaining some of the different clocks in the system, instead of directly answering a confusing question.

The idea of “delivering the enhanced clock signal for Roon to use as the reference clock” flat out does not make sense. It’s just not how this stuff works. It’s not really possible to have a clear discussion about this if the concepts of a USB/data transmission clock and the audio clock are blurred together.

@Antonio_Bendezu

If RAAT does indeed tend to make the sound “better,” then it makes sense for @gasman and others to ask whether reclockers or other USB enhancers get in the way of or are ignored by Roon.

Except–this isn’t actually a question about RAAT. The answer is self-evident just looking at how USB Audio works in isolation. USB enhancers are about compensating for some shortcomings of USB, and don’t really interact with RAAT at all. If they have an effect at all, that effect will probably be the same with RAAT as with other transmission mechanisms.