We Need To Talk About Ones And Zeroes

@sns 

So on top of Qobuz using TCP/IP protocol

I know Qobuz claims to use TCP/IP but to many people, and it seems to many here, the internet is synonymous with TCP/IP.  TCP is only part of the internet. I have tried to show that UDP/IP is equally ubiquitous, and that conclusions on accuracy drawn from TCP do not apply to UDP.

Qobuz also claims on their website that "An analog audio signal is composed of a sine wave" when they probably mean an infinite set of sine waves.  They are careless with the truth.

Streaming is different from downloading, which can be bit-perfect using TCP/IP.  The functional difference is that you can start playback of a stream before it is complete.  Nothing in the world can guarantee the future will be error free.

TCP/IP only guarantees bit perfect transmission after the transmission is complete, and cannot guarantee how long that process will take.

Qobuz is very tight-lipped about the actual protocols used, which are proprietary. It is possible that they make a stream up from many small files which are transmitted using TCP/IP, but nothing guarantees all future files will be ready when playback gets to where they are needed.

The Euphony article you quote illustrates this well:

The best way to do this is to preload the complete song to RAM before playing

It does not address Qobuz but the major streamers have the same issues to face:

We don't know that much about Roon's internal workings

@devinplombier 

Audio streaming presents a very, very light load in Ethernet terms, and error-free transmission is a given

It is not a given, not by Ethernet.  Ethernet on its own does not guarantee packet delivery, nor timing, nor error-free status.  You need higher level protocols, which may operate over Ethernet, if you want to guarantee delivery and error correction. 

Ethernet timing is indeterminate, because unlike USB there is no central controller managing timing.  However, as you point out, it is usually fast, depending on the version.  Early Ethernet was under 3-million bits per second, though, which is not really enough for a CD let alone high res.  Ethernet does have significant overheads.

You might care to rethink your statement that latency is not important for audio. It is the reason streaming was introduced.

Also most Ethernet network components including routers, switches and gateways do include processors and do a fair bit of work on each packet.  They build up lists of Ethernet devices connected to each port and only forward packets to the necessary port(s)

@chrisoshea 

My advice to all on this thread…. Buy a Rega Planar 3, a Schiit Mani 2 phono stage and some records

I would say get a universal disk transport with HDMI outputs, and some SACDs, Blu-ray audio disks, 4K opera recordings and CDs.   You will always have your media, and it will always be as new because it won't wear out. Keep your fingers crossed that somebody will still be making transports if yours carks it!

Having said that, I have started buying records again ... but not if the music is also available on SACD!

So I asked the web about "ethernet packet delivery guarantee" and Google's AI overview came back with:

Ethernet, at its core, is a best-effort delivery protocol, meaning it does not guarantee that every packet will be delivered or that they will be delivered in the order they were sent. While Ethernet frames are encapsulated in IP packets, which in turn can be part of TCP or UDP protocols, the underlying Ethernet layer itself doesn't provide delivery guarantees.