Hi Brian, I am new to Roon (life time sub), and thanks for explaining how RAAT, clocks, and different components work throughout the digital signal path. I have some specific questions on my setup and hope you can help. My setup is, Synology NAS (music library and Roon Core) - Ethernet via a switch - dCS Network Bridge - SPDIF (Coax) - Chord Qutest DAC.
(1) I like the idea that RAAT allows the clock of the DAC to control the timing of pulling the data. However, since the connection between my streamer and my DAC is SPDIF (my dCS streamer doesnât have USB output), does the RAAT control stop at the streamer? In other words, does the clock in the streamer fight against the clock in the Chord DAC? I want to understand the dynamics between these two clocks?
(2) Related question - if Roon cannot see my DAC or monitor the buffer of my DAC, do I completely miss the most important benefit of the RAAT architecture?
(3) However, on the other point, after reading the difference between data and signal, if the whole streaming process from the Core to the buffer of my DAC is nothing more than copy and paste, and assuming Chord DAC has sufficient buffer, should I not be worried about the two clocks fighting in my setup, as these two clocks are doing two different types of clocking?
(4) I have an option to upgrade from my dCS Network Bridge + Chord Qutest to the new dCS Bartok network DAC, which seems to be me will be able to resolve the SPDIF problem and let RAAT see/control all the way to the DAC. Do you think it is worth the upgrade? With the Bartok DAC, can Roon see all the way to the DAC section and control the level of its buffer?
Hi Ryan
If you connect your DAC through SPDIF, the DAC will synchronize to the clock of the source delivering the SPDIF signal. Nothing RAAT can do about that. Given you are using a dCS Network Bridge, the quality of the clock is probably not too shabby.
However if you do have the opportunity to move from your setup to a Bartok (and your budget allows), I would definitely do that. I have a dCS Rossini and it has been the best investment I have ever made in audio. The dCS Rossini was selected after listening tests of an 18 year old dCS Delius / Purcell combo against Chord DAVE, Merlot Playback Designs Merlot, Weiss DAC202 and the dCS Methusalem held its ground.
My Rossini is V1.1 and will be upgraded to V2.0 shortly (through software). The current Bartok is supposed to achieve sound quality of Rossini 1.1 so you will be in for a real treat. And Roon to control a dCS DAC is outstanding.
Brian mentions clock quality vs. coherence and states that the discussion in his post is related to the latter. Most audiophile discussions of clocks have to do with clock quality (accuracy) since that has an impact on the rate at which the DAC operates. The problem here is that many see âclockâ and assume that the discussion has to do with jitter or some other audible thing. It doesnât.
Clock quality deals with the accuracy of the clock in the sense that for any given âtickâ of the clock does the subsequent âtickâ happen at exactly the right time or is it a bit early or late. Early or late is potentially bad as it will have a potentially audible impact on the analog signal that is output by the DAC.
RAAT doesnât deal with that at all.
Clock coherence deals with the difference between two or more clocks if started at the same time and observed over time. In a perfect world youâd sit two identical clocks side-by-side, start them at time=0, and observe that they remain in sync with each other forever. In the real world thatâs not going to happen. Ever. The two clocks might be really, really, really close but thereâs always going to be some drift between them. (this is due to the fact that clocks are always based on the observation of a physical phenomenon and slight differences in the physical system will always lead to differences in measurements).
For the purpose of digital audio, that drift may be irrelevant and in many cases it is. If the drift, either total or inter-sample (jitter), is small enough itâs not going to exist at a frequency that has any bearing on audio.
For the purpose of data management itâs a big problem.
With a DAC the output is open-ended in that it can be running slow or fast and the bits that come in are going to make it out as an analog signal. The signal might be distorted due to clock-related anomalies, but nothing is going to stop the DAC from taking bits from one side and outputting analog on the other.
When youâre talking about moving data between buffers youâre dealing with a completely closed system. Say you have two buffers (A and B) and each one is controlled by a separate clock (cA and cB). Data is moved out of buffer A at a rate defined by cA and the same for buffer B and cB. In this case buffer B is feeding the input of a DAC and cB is managing the drain of B as well as the DAC itself.
The two buffers have a defined size and for practical purposes should be kept as reasonably small as possible.
Now, set this system into motion with the assumption that the two clocks are at the same frequency. For each sample copied from A to B there should also be a sample moved from B to the DAC. If the two clocks are perfectly coherent (in sync with each other) then this works very well and there are no problems. That never happens in the real world. One of the clocks is always going to be faster than the other and if the system is allowed to play out over enough time then one of two things IS going to happen.
If clock A is fast then B is going to fill faster than itâs being drained and will eventually fill up. Once full you have to figure out what to do with the next sample.
If clock B is fast then B is going to empty faster than itâs being filled and the DAC will eventually run out of data.
Dealing with clock coherence is trying to solve this problem in the most efficient way possible such that B is never allowed to overfill or empty completely. This is the problem that RAAT is solving, and youâll note that it has nothing to do with clock quality which is the thing that audiophiles are concerned about when they talk about jitter.
In a system such as Roon there are tens (or hundreds) of buffers in play all driven by different clocks. In order to ensure that the buffer sitting next to the DAC never runs out of data or overfills RAAT needs to observe the clock that controls that buffer. In some cases that simply cannot be done so RAAT needs to watch a buffer that is as close to the DAC as possible.
If Roon can model the behavior of that far-away buffer then it can be sure that itâs always sending data at a rate thatâs not going to allow it to overrun or run out.
In your case RAAT can see as far out as the output of the Bridge. Neither Roon nor the Bridge itself have any idea of whatâs going on in your DAC (which has its own buffers).
No, and in fact due to the nature of S/PDIF your DAC is syncing to the clock in the Bridge by reconstructing the clock signal from the audio signal. The Bridge is in control of the downstream operations.
In this case RAAT can infer whatâs going on in the DAC since the DAC (and its buffers) are synced to the clock in the Bridge (which RAAT can observe).
The benefit of the RAAT architecture is ensuring that the data received at the DAC is complete (always) and the buffer feeding the DAC is at the right level. You are getting 100% of the benefits of the RAAT architecture. Since your DAC is syncing to the clock in the bridge then RAAT knows what it needs to know about what is happening downstream.
Youâre getting it. RAAT is concerned about a different kind of clocking problem (coherence) than the problem most audiophiles are concerned about (jitter). RAAT has no knowledge of your DACâs buffer, but as long as itâs properly synced to the incoming S/PDIF signal then it doesnât matter. Everything just works.
In your current setup you have the following data path:
Streaming input (RAAT) > DAC FPGA > Ring DAC > Analog
If nothing else itâs a shorter signal path which poses fewer potential areas where something can get messed up (Iâm looking at you S/PDIF!!!)
In terms of clocking, all of the components in the Bartok path are synced to the same clock.
It canât as it has no knowledge of whatâs going on inside the DAC, but that doesnât matter as any buffering or other processing done inside the DAC is done in lock-step with the same clock that RAAT is looking at. In other words, as long as RAAT is managing its buffer correctly then youâre getting all of the benefits of RAAT.
Given the two options you present the RAAT parts of it are identical. The differences come down to the signal path, DAC architectures, and quality of implementation.
Go listen to a Rossini and compare it to your setup. If you prefer the Rossini then youâll prefer the Bartok. If not then thereâs your answer.
First of all, thanks Andrew for the very in-depth responses! Very helpful and educational! I do have two follow up questions:
(1) Can I interpret this, very generally (over simplifying for sure), as that clock quality = audible SQ, and clock coherence = filling the buckets (buffers) at levels not too full but not too empty? As to coherence, if the buckets do not get filled properly, it could lead to dropouts, skips, or dramatic distortion, which however would not happen until it hits those extreme levels (too empty or too full); therefore, we can generally say it is not audible or not an audiophile level SQ issue, because a little fuller or a little emptier in the buckets (in between the extremes) wonât create any audible delta in SQ?
(2) This is good to know, at least now I do not feel as bad that the SPDIF from the Bridge is a major drawback (plus they stopped implementing the USB output). Letting the Bridgetâs clock to control the pace sounds good too as you would think the clock quality inside the Bridge should be better than the one in Qutest (purely speculation due to the price tags)? A little more insight, does this mean that, with SPDIF, the clock inside Qutest is disabled or forced to sync with the clock of Bridget? However, how does this fit into Chordâs claim (many other DAC manufacturers also say so) that all Chord DACs will re-clock the incoming signal to minimize jitter (not an exact quote but they generally told me so)? And they also claim that with their FPGA platform and the large amount of filter taps (49K in Qutest), there is no measurable jitter. This sounds to me that Qutestâs clock will continue to work its way as if SPDIF or USB has no impact at all. Am I mixing up different things here?
Really appreciate this, now I understand what can go wrong in the signal path, you perfectly pin pointed what i will be paying for (shorter signal path without SPDIF, no interconnect needed, better DAC hopefully) if i do decide to go for Bartok.
Thanks Andrew! One more question - how does âRendererâ fit into the RAAT framework, or which component in my current setup is the âRendererâ? I have seen this term so many times, but never seen a definition.
OMG, this is certainly one of the most important articles published in an «audiophilesâ» environment. Wish it could be made compulsory reading for anyone claiming there are audible differences between different computer USB feeds to the same external DACâŠ
I (think I have) read the above but itâs way over my head
A simple question
Given Roon RAAT as the feed on Ethernet, a RPi 3 as the End Point and an Audiolab M-DAC .
From. Clock point of view Would I get a better performer using USB or SPDIF via an Allo Digione. My DAC maxes at 24 96 on USB hence the Digione to get 24 192 , but with a performance question ?
SPDIF is a push technology. The endpoint pushes the data to the DAC at the speed of its own clock. The DAC is forced to follow the clock of the endpoint
(async) USB is a pull technology. The DAC pulls the data from the endpoint at the speed of its own clock. You are (theoretically) independent of the quality of your endpointâs clock
Given the choice to go 24/96 via USB or 24/192 via SPDIF, I would probably chose the former.
Quality wise, the law of diminishing returns starts kicking in beyond 24/96kHz, so the better clock in the DAC will likely offset any potential gains from increasing samplerate from 96 to 192kHz.
Hereâs a description of the Audiolab M-DAC from Qobuz
It seems the M-DAC has a realtively old TAS1020B USB receiver, which is âonlyâ USB 1.1 isochronous, not 2.0 async such as current XMOS or C-Media chipsets. https://processors.wiki.ti.com/index.php/TAS1020B_vs_TMS320C5533_Comparison
So I am afraid, what I said above does not really hold. In my book it is open which connection will give you better SQ.
Do you have a hifiberry Digi+ Pro HAT on your RP3 or are you using USB? The RP3 shares one controller for ethernet and USB which does not help the quality of the USB out. Adding a Digi+ HAT gets you around that limitation.
The Digi+ Pro has reasonably good clocks for 44.1 and 48kHz. An Allo Digione would probably need to be the Signature version to improve on the hifiberry.
By the way: the terms isochronous and asynchronous are not mutually exclusive in USB audio jargon, and refer to quite different things.
The USB audio class specification mandates use of isochronous transfer, which relates to how audio samples are batched together and transmitted so as to receive a guaranteed amount of available bandwidth on the USB link.
Asynchronous is an optional part of the audio class specification which allows the receiver (DAC) to give the sender (endpoint, in your message above) information about the overall rate at which samples are being sent and consumed, so that the transmitter ends up sending at the rate determined by the receiverâs clock.
You are right, I stand corrected. In the meantime I have found the Service Manual of the M-DAC and it says that the TAS1020B implementation in the M-DAC is capable of asynchronous mode.
So my advice would slightly change
If you have an endpoint with a good USB implementation, use that. This would not be an RP3, but an RP4, a Celeron NUC, an Odroid C2 or another device that has separate controllers for USB and etherent
If you want to continue using your RP3, add a hifiberry Digi+ Pro HAT and use SPDIF
Well then you seem to be set. I see no benefit in going to USB with an RP3, quite the contrary.
No harm in trying out USB though. Curious whether you can hear an obvious difference.
I think basically you are right. But it is not as simple as that. Some SPDIF do not go directly to a DAC but are buffered and then distributed to a system. There push or pull is not an issue. The receiver will reclock and also delay the signal before it is output.
Sorry, I do not understand the point you are trying to make. I am fully aware of the RAAT protocol vs. the USB architecture - and brianâs critical remarks in posting #38
