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) > Bridge FPGA > S/PDIF driver > S/PDIF cable > S/PDIF receiver > whatever happens inside your DAC > Analog
In the Bartok it looks like this:
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.