I agree, just would like to see it tested 
Hmmm… Not so. From the clarification above, all Roon is RAAT! Makes sense, the Roon team focused on audio output over a network streaming interface, and then bridges that over to USB with another process if it is a local USB output on the core.
I imagine that many RAAT implementations in streaming DACs do exactly the same on the DAC side: they run the client and output into the USB implementation in the DAC, while others output to something a little lower level possibly.
The difference I am getting at is the difference between connecting a DAC to the core via USB (which in my experience depends on the USB receiver implementation, the cable, and the source implementation) Vs RAAT alone.
That is:
Case 1:
[Core → RAAT → RAAT to USB bridge] → USB cable → [USB receiver → DAC]
Vs
Case 2:
[Core → RAAT] → network → [RAAT client → DAC]
and what I am wondering about is, in Case 2, whether the portion [Core → RAAT] is sensitive to the choice of hardware.
No, not at all. A simple question from my simple mind. When I connect my DAC to my ROCK machine using a USB cable, is RAAT involved?
I see a lot of info about TCP/IP in @john’s post, but nothing about a USB connection.
If it doesn’t use RAAT for USB, then what does this, from the Roon RAAT KB article, mean?
I just learned it is. Roon ONLY outputs in RAAT format, there’s a separate process within your local machine taking that RAAT output and bridging it to your USB device.
Yes, RAAT is used to route the audio data from the Roon Core to the Roon Server, the Roon Server then then sends signal to the output device that has been selected.
In the case of a USB device being selected the USB Audio protocol is used to get the stream from the Roon Server to the device.
A simplified signal path looks a bit like this:
Storage → Audio File Data → Roon Core (decode, transcode, DSP, … as required) → RAAT → TCP/IP → RAAT Server → USB Audio → USB Audio Device → I2S → DAC.
The Roon Core process and Roon Server process can be on the same machine or on different machines, but either was the communicate to each other via TCP/IP.
I2S I think most DAC use this internally but could I be wrong here, however, either way just think of it as internal DAC routing from USB port to DAC chip.
1 Like
@carl, thanks for the clear, straightforward answer…
So, in the context of @miguelito’s original question, RAAT in the ‘preliminary’ stage of a USB connection is irrelevant.
So, so sorry I brought it up. 
1 Like
What hardware? The machine Core is running on? I would like to understand what makes you think that can possibly be relevant, from one physicist to another.
Right. Another way to ask my question is whether people have experienced any difference in sound quality if the portion:
Audio File → Roon Core (decode, DSP, … as required) → RAAT
Is run on a run of the mill machine or a high end server.
I have no experience of high end servers, nor do I intend to get any, because there is no logical or rational explanation as to how they could possibly make a difference. That said, I’m sure there are a whole bunch of people (i.e. high end server owners) who will tell you otherwise 
Right. Although I do understand how SPDIF or USB can sound different with different cables and sources, those same reasons don’t apply, TO MY KNOWLEDGE, to the TCP transport method.
Which is why I am wondering what the answer is. I suspect the answer is no it does not matter one bit (pun intended) but no-one I trust in the audio reviewing world has ever, to my knowledge, said so.
I didn’t know this, why do the cables affect the sound?
2 Likes
They can induce jitter for example. The most striking example is with toslink vs coax - it is the same exact data but toslink, in my experience, sounds worse. I have read it is because of the poor quality of fiber that is allowed in toslink connections.
2 Likes
My opinion based on my technical knowledge and experimentation is that provided the device running the Roon Core has adequate resources there is no difference in SQ … it’s always a bit perfect stream that is routed to the Roon Server process.
When the core does not have adequate resources, the audio stream may break up (and data is lost) resulting in clicks and pops. As can be demonstrated when attempting PCM to hi-rate DSD conversion on an underpowered core.
1 Like
Yes of course, this is understood.
1 Like
As a scientist, I would have naively assumed that no digital source matters. USB data is the same as SPDIF, the same as I2S, etc - the same exact 1’s and 0’s are recovered.
However, this is not the case: there’s jitter at the source, electrical noise transmitted from a poor USB implementation, etc etc etc. So these “perfect” transmission in content sounds different because of the timing of that content or because of additional noise generated.
For the RAAT case, the same issues do not apply. But it is conceivably possible that two pieces of hardware on the source side would generate different levels of error packets which then the receiver needs to re-request (as it is checking and correcting using TCP). A higher level of activity from re-requesting tons of packages from the source could reduce sound quality.
However, I have never seen a network communication with tons of errors at all - there are essentially no errors by and large with even the most basic equipment.
So I am skeptical that this is a thing, especially given I don’t see any reviewers saying it is a thing, but as a scientist I always keep an open mind for things I don’t expect.
You would think analog cables, as long as they are reasonably well built, don’t make a difference. In my experience they do.
1 Like
So there seems to be a practically infinite pool of people, some with scientific or engineering background (or both), who still believe in this kind of “etc. etc.” I can attribute that only to a lack of understanding of how digital transmissions work, or how digital audio works, or both. These topics have been covered extensively on this forum.
6 Likes
Many people think it’s the other way around, since optical offer galvanic isolation. Pick your own bogeyman: jitter or electrical noise. Good DACs can successfully deal with both, at least to the extent of making them inaudible.
2 Likes
Those people need to listen! SPDIF, in its kosher implementation, needs to recover the clock from the source - just recovering the data is not enough. There are many high end optical implementations using high purity glass and high speed transducers on each side that work great - toslink is NOT one of them.
… and USB data transmission actually is differential as well (my SMSL M300MkII works with ground and +5VDC removed) in all its implementations, USB C, 3 and 2 variants, see following pin out screen shots
Yes, thank you for reminding me of that. Most (all?) USB cables use a shield and ground though, which somewhat negates the differential nature (and by the way so do Cat7 cables, which is why they are sometimes adviced against in audio equipment).