RAAT is a network protocol. It delivers data from a server (the Roon Core) to a device–for example–in the purest case–a networked DAC. When we compare clock relevancy here, we are comparing apples to apples against other network protocols–many of which make the computer’s clock an inherent part of the audio chain in a way that RAAT avoids.
When you start to insert additional elements–USB, or an S/PDIF generator, or a “USB re-clocker” or whatever–it’s important to think critically, thoroughly, and specifically about how each of those aspects work. These considerations are totally independent of RAAT, and are characteristics of those other systems. RAAT does not extends its fingers into your USB DAC and fundamentally change how USB works.
One of the most frustrating things about discussing clocking and related concepts in this setting is that it’s quite complicated, and there is a tendency to hand-wave, or to misuse or conflate terminology. A lot of people get their information from marketing sources that sometimes play fast+loose with the technical details.
For example, in your question, you are talking about totally kinds of clocks which impact the system in totally different ways and thinking that maybe that our discussion of one kind of clock applies to the others just as well. This confusion is partly on you, and partly on us, but it is a good representation of the general state of affairs.
Lets remove RAAT from the equation for a second and talk about a typical USB Audio 2.0 playback case:
- Computer connected to USB Audio 2.0 device
- Asynchronous clock mode / Isochronous data transfer mode
- USB interface inside of the device communicates to a DAC chip using I2S with an MCK wire
There are many clocks in this system:
- A clock in the USB interface that pushes USB packets onto the wire one bit at a time.
- The system clock in the computer, which governs the operating system scheduler, which decides when who’s code gets to run on the computer.
- The CPU’s cycle clock, which determines when individual CPU instructions run
- A clock in the computer which determines when isochronous USB packets are generated (each contains 125us of audio–so we are not talking about sample resolution here)
- A clock in the DAC that drives the USB interface via the MCK line and helps form the actual edge transitions on the I2S wires that feed the dac.
When audiophiles talk about clocks, they are usually talking about the last one. The most common explanations for “why jitter matters” only apply to the last one. When we talk about RAAT driving audio playback with the appropriate clock, we’re talking about the last one too.
USB enhancements, on the other hand, have no bearing on that clock. They’re concerned with other aspects.
The other ones are there, doing clock-y things, too of course…
- If the first one is out of spec, your USB device will fail to communicate with the computer
- If the second one stops counting time, the music stops
- If the third one is running too slow, the CPU might get to 100% and fail
- If the fourth one isn’t firing at the right rate, you might get dropouts
So they’re not totally uninvolved. All must be working properly for you to hear the music.
There is a relatively well understood concept about how jitter in the DAC clock only causes distortion during digital to analog conversion. I’ve seen this explanation mis-applied to USB re-clockers and other enhancement products often. That’s not to say that all clocks don’t have measurable jitter or that those measurements can’t be improved–it’s just that that their jitter numbers don’t relate to sound quality via the same mechanism.
According to the USB specifications, receiving devices are not supposed to care about these differences so long as they are within spec. If a USB device requires a computer to generate a USB signal that goes way beyond the spec requirements of USB in order to achieve its full performance, has the device designer really finished the job?
The point of these standards is to support free interoperation without these sorts of concerns–so I am always a little bit disappointed in the DAC when I hear that an “USB enhancement” product has made a big difference.
Finally…I’m a natural skeptic of claims that don’t come with a clear explanation of the mechanism of improvement, and that aren’t backed by either measurements or rigorous subjective testing. A great many products are made solely on the basis of someone’s theory + informal listening tests by a few people performed to “validate” it. I am not a huge fan of this method.
I prefer to talk about concrete engineering choices. For example–the one you refer to. AirPlay forces audio devices to conform to the computer’s clock rate, whereas RAAT drives transmission rates based on the DAC’s clock (the “last one” above). There’s no claim about differences in sound quality in that statement–if you understand the technical concepts it will be clear why ours is the better engineering approach–and this is enough of a reason to do it.
One last thing, since this topic made me think of it–Bearing in mind that John has a personal interest in USB enhancement products, he does a good job of exposing some of the complexity inherent in reasoning about USB in audio systems here.