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.