I have read somewhere that the data transfer between Roon and a Roon ready device happens according the TCP protocol. It means that packages of data are transferred with headers telling the receiving end what package to receive and what’s it’s place in the stream. So the music gets perfectly rebuild in the buffer of the dCS device receiving it.
If I understand this correct it means that timing errors are out of the question once the music is in the buffer and played from there.
I have noticed that when you unplug the Ethernet cable from the dCS while playing music the song keeps playing just fine.
Are missing packages (maybe unlikely) resent like in file transfers between computers and hard disks?
It would make the choice of Ethernet cable between Roon and dCS receiving endi less important. Except for isolation of electrical noise coming from the source itself or from WiFi and other wireless radiation contaminating into the cable.
And, is Roon unique in using ‘packages? Does for instance Audirvana on my iMac connected to the network over Ethernet also use tcp? I was thinking that streaming is a direct flow of pure pcm and that a good cable would diminish the change of timing errors (like with coaxial cables for instance). How is that with USB?
That is correct. Timing and jitter have no place in any discussion of the network side of networked audio. These only become issues when the last buffer in the chain is fed into the DAC itself.
In networked audio the data is buffered many times in many different places. In our products the very last buffer is slaved to the DAC’s clock and it is the source that the DAC sees. Everything that happens prior to this point is irrelevant in terms of audio reproduction. Until it’s in the final buffer it’s just data.
Yes, In both network transfers and transfers to/from disk packets that are lost or corrupt get re-sent. This is generally true (definitely with TCP), but there are some specific cases in which lost packets are truly lost. The most useful example of this is asynchronous USB audio. If a packet is dropped in this case, it’s gone forever.
YES!! The only really critical factor is that the cable meets the correct specs for Ethernet at the correct category level. Most audiophile Ethernet cables fail this test.
Ethernet is very good at rejecting environmental noise and this is part of the reason that a proper cable be used. Again, this is where most of the audiophile cables fail. They sound different because they change the noise component in the analog section of the DAC.
Roon uses standard networking protocols. Mosaic and Audirvana and everything else that talks over that network connection do the same (packetized data).
There are no timing errors or jitter with a network connection. With a coax (S/PDIF) connection this is not the case as the data is sent in real time and there is no chance to reorder or re-send. Jitter / timing is only important with interfaces like S/PDIF or AES (and to a lesser extent, USB). In these cases proper cables are very important.
USB is a completely different animal and has its own issues relating to noise and timing. It seems simple on the surface, but under the covers it’s complicated and full of compromises. USB is best avoided if the DAC supports a network connection.
Picking up this thread, and expanding on your point that whatever happens prior to the last buffer before the Dac (which in the Vivaldi stack I believe is the upsampler) is irrelevant, there shouldn’t be much benefit in investing in a switch that could be synced to a 10 M master lock, which in turn would sync the Vivaldi clock. Did I get this right?
Thanks for being straight forward. It is rare to see this kind of remark nowadays. I see people investing large sums of money in servers, switches and clocks, only to connect them via Ethernet. I never thought it made sense. Anyway, thanks again
See @Andrew 's excellent summary here
Ethernet cables should be unshielded. No shielding on the individual wires, no shielding for the cable itself. Its called U/UTP
Is all you said about TCP and Ethernet cables still true when using Mosaic and Tidal ?
I ask the question because in that case there is no server (or TCP server) between the Internet router and the DCS Bridge (in my case Bridge + Vivaldi DAC).
Yes. Until it is spooled out of the last buffer into the DAC itself it’s just data. No different than any other data that moves over a network. All of the same network protocols are used and there’s nothing special about an audio stream compared to any other network traffic.