Is Roon RAAT lossless / error correcting in-transit?

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?

1 Like

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

1 Like

This thread, including a response from Danny, states that RAAT utilises TCP/IP error checking.


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.

Hence my inquiry…


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! :smile:

I wouldn’t mind spending money on a high end server but would like to know if it is worth it or not.

If by this you mean that RAAT is strictly for networked systems, I don’t believe that’s true.

From reading this article it would seem that RAAT is also, at least, used with USB.

I did mean RAAT over the network. I thought connections over USB are strictly USB-Audio based.

1 Like

No, I don’t think so.

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.

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.

1 Like

Here is the signal path for a DAC connected via USB: ROON uses RAAT for USB as well.

1 Like

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.

Are you saying you hear no diffs between cables, servers or network vs USB?

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 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 / 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” ( 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.


I thought

would of done a video on this but so far he has only tested cables, DACs, AMPs, CD transports and power related products.

I’d be curious to see this put to a test as well, odd that there aren’t any full detailed testing videos on these servers.

Although I am a physicist by training, and I believe everything should be measurable, what ASR does is way too simplistic in my opinion.

1 Like

If you accept that RAAT is bit perfect, using a high end server shouldn’t make any difference, i.e. the endpoint receives the same data either way.

Hi @xxx,
I think we discussed RAAT in the past but it was a long time ago now, does @john’s post clear this up for you?