Ok, so I got your attention with the subject line… I really mean error-correcting.
The USB Audio protocol is not error-correcting. This protocol is different from the one used for hard drive transfers, etc - errors are not corrected and left unchecked. The key difference with SPDIF is that it has flow control, so the receiver can tell the transmitter to slow down or speed up. This allows reliable reclocking on the DAC side - with SPDIF you always run the risk of buffer over/under run.
RAAT on the other hand works over the network. Network connections are themselves error-correcting: if a packet does not check for integrity it is re-requested from the source. There’s no difference in music over RAAT and any other network traffic in terms of network communication.
So the question is: Is this all correct? Is the RAAT client on my DAC guaranteed to receive data without errors?
And related to this, a question that I have NEVER found a definitive opinion or answer to from people reviewing audio: Does the Roon core computer matter when playing over RAAT?
The USB audio protocol is not error-correcting, but it is error-checked by means of a CRC embedded in each data packet. This CRC is present in all USB data packets, whatever higher-level protocol they are part of. USB controllers receiving packets with an invalid CRC will normally notify the driver of the bad frame but the packet will be discarded. What effect that has on the audio stream is not defined by the standard, as far as I remember – for example, it could result in a drop-out, or the audio playback software could perhaps try to interpolate
I should have not said “left unchecked” but rather “not corrected”. These subtleties (as well as USB receiver design) explain why USB cables and high quality sources matter for this (also due to the electrical connection there can be electrical noise passed on from the source).
Given the error-correcting nature of TCP/IP, and the fact that it is a differential non-grounded pair communication (should not use shielded ethernet cables!) I find it hard to think of a way that the quality of the server running Roon core matters at all.
In my setup for example, I have an optical (SFP-Ethernet) bridge to my dCS Rossini and I have tried multiple servers for Roon core: dedicated mac mini, mac laptop running macOS, macpro running macOS, old mac laptop running Ubuntu, and as of late a NUC10i7 running ROCK. I have not detected any sound quality differences between these when playing over the network.
A matter of opinion…personally I don’t think it explains what you said, because the artefacts from missing USB packets are not the kind of things that people normally discuss under the heading of sound quality; that discussion usually assumes bit-perfect delivery and argues about jitter, noise, etc. If you are losing USB packets - which is very rare in a properly-built system with cables that conform to the relevant standards - then obviously you don’t have bit-perfect delivery to start with.
Regardless of the reason, most people that have tried have experienced differences with USB cables and the sources they connect to.
However, I have never seen a reviewer look into network streaming carefully to answer the question whether using a high end server changes the sound quality or doesn’t.
In fact I had one reviewer tell me privately that if it doesn’t change the sound quality it is “not interesting to talk about”. Which of course it is. I think he’s worried Innuos might take the server he has on long term loan away!
I wouldn’t mind spending money on a high end server but would like to know if it is worth it or not.
I could be mis-remembering, but I think I was set straight on this a long time ago.
Then there’s this implication about RAAT devices from the article I linked.
Not sure that affects your basic question, tho.
Bill_Janssen
(Wigwam wool socks now on asymmetrical isolation feet!)
11
I assume Roon will chime in on this, but I’m pretty sure RAAT transport does not run over USB; @miguelito is correct in that USB Audio is used over USB. The Roon article is somewhat unclear in the way it explains this.
There are a number of ways to emulate Ethernet over USB, which means that one could theoretically run RAAT over USB using Ethernet emulation, I suppose, but I’ve never seen any of them mentioned in this context.
Not I, although I seem always to be trying to find them. My experience includes comparing Roon RAAT (LAN) with Roon USB using the same course and target.
Considering the fact that, using USB, you can plug a generic DAC into a Roon Core and have it work suggests that RAAT is NOT used over USB. After all, the generic DAC does not have Roon or RAAT built in to it. All the DAC knows is USB Audio…
I get the impression that the “RAAT” naming is more to indicate that, over USB audio is sent using the USB Audio protocol, but there’s additional control functions such a volume control.
Regardless, the definition of RAAT is a bit of a side topic - the point is using network to send data.
RAAT is a way to losslessly transfer raw PCM or DSD samples from a Roon Core to a RAAT client.
In its current state, RAAT utilizes TCP to move data over a TCP/IP data link.
RAAT clients accept an incoming RAAT audio stream and output it using an “output plugin” that encodes the raw PCM or DSD samples in the required format for the audio device.
Here’s where I think there may be some confusion: When you run Roon.exe or Roon.app on Windows/Mac/Linux you are actually running two processes—the Roon client that you interact with and a separate process called “RAATServer”. You can see this if you open up Task Manager.exe / Activity Monitor.app / Top and filter for “RAATServer”.
The RAATServer process is a RAAT client like any other. It automatically configures itself with the correct “output plugin” for the platform it’s running on (ie. WASAPI on Windows or CoreAudio on Mac) for bit-perfect output to the audio driver.
When you play audio to a “local” device on Windows/Mac/Linux the audio samples are being passed over the TCP/IP stack regardless if you’re running Roon Core on that computer (all-in-one/AIO) or using a split Roon Core / Remote setup (ie. Nucleus → Windows PC). When running in all-in-one mode the Roon Core process sends the RAAT stream to the “localhost” (127.0.0.1) address which is then looped back through the network stack and received by the RAATServer process on the same machine.
Think of it this way: the Roon Core actually has no idea what an audio device is or how they work (for RAAT outputs at least, airplay et. al are different and outside the scope of this post). The Roon Core’s responsibility is to:
A. Decode audio files/streams (FLAC/MP3/AAC/DSF/DFF/etc) into raw PCM or DSD.
B. Apply DSP processes to raw PCM or DSD samples (if desired / required for compatibility).
C. Output raw PCM or DSD samples via RAAT to RAAT client at a given location on the network using TCP.
It’s then the RAAT clients job to accept these raw PCM or DSD samples and format them in the way that the audio endpoint requires.
