Sorry, this makes no technical sense. RAAT is a an asynchronous protocol layered over TCP. That means that exact timing does not matter, and it has error detection and correction. RAAT packets arrive at the endpoint and are reassembled in order in a buffer.
It’s after that point that things become trickier. If your endpoint connects to the DAC with a synchronous protocol like S/PDIF or I2S, accurate clocking is important for accurate signal reconstruction in the DAC. If the endpoint uses USB to speak to the DAC, clocking is not as important – the DAC reassembles the buffered bitstream with its own clocks – but there could be digital signal errors from mediocre circuitry or cabling because USB audio has no error detection or correction. Finally, any endpoint-to-DAC electrical connection (USB cable, S/PDIF coax, AES, I2S) may carry electrical noise from the endpoint’s digital circuitry or power supplies that leaks inside the DAC to the analog side distorting the analog output. This problem may also arise if the DAC is directly connected to the core with an electrical connection (USB, coax, AES, I2S).
Optical S/PDIF avoids electrical noise in endpoint-to-DAC connection, but very accurate timing (which is needed because S/PDIF is synchronous) is harder with not-super-expensive optical components.
A well-designed and built DAC has filtering and isolation (such as transformers) circuitry to block electrical noise from input connections, and does also a lot of work to achieve very accurate timing of the bitstream that is the input to the actual D2A circuitry. Such a DAC can work well with almost any USB source.
Was warming up for an explanation but @Fernando_Pereira has said it better than I could. When talking about USB noise I was talking specifically about the unlikely possibility of RF transfer from core to DAC.
Ubuntu is an OS for a general purpose computer; ROCK is built from the ground up to run a Roon appliance. ROCK is derived from the work done for the Nucleus product. See the section on Roon OS in the Nucleus White Paper.
Well, ROCK is a very stripped down Linux with integrated Roon server. You cannot install any other software in ROCK, nor do you have shell access to the system. ROCK has a web interface for the basic tasks, and that’s it. You cannot monitor ROCK’s resource usage or internal component temperature, and it has very clear ideas of where it will look for music folders. All that is so on purpose, to make ROCK the basis for an appliance-like Roon server, one you install and forget about, one you don’t have to know anything about system administration.
My personal view about this is that all this is cool and fine as long as it works. As soon as hardware or software problems occur it seems to me quite a bit more difficult to get to the ground of the problem on ROCK than on a multi-purpose OS like Ubuntu, where you have at your disposal many monitoring, diagnostic and administrative tools. For those without any clue about OS and systems it certainly is a good alternative, as long as they use ROCK on one of the NUC recommended and supported by Roon.
For my personal Roon experience I decided to not use a NUC but a mini-ITX board and assemble on base of that my fanless core server. I probably could have made ROCK work on that platform, but it would have been a so-called MOCK system unsupported by Roon, and I felt that with any problem I would easier get help from the vast community of Debian and Ubuntu users than from the quite small community of ROCK users out there. And, well, you simply can use a multi-purpose OS on a single-purpose computer as is my Roon server.