We Need To Talk About Ones And Zeroes

@devinplombier 

together with all the AI-generated nonsense @richardbrand has been cut-and-pasting in this thread

Google AI has access to all the nonsense on the web, including yours, but it is intelligent at processing the entire content.  If the consensus it reaches agrees more with my understanding than yours, think perhaps that you just may not be entirely right.

What I have tried to do here is to back up three assertions with the best sources of information you just might believe, one being Wikipedia and the other Google AI.

You labelled this topic "We Need To Talk About Ones And Zeroes" and we clearly do, because there is so much misinformation surfacing here.

My backed-up assertions are

1. Streaming does not guarantee packet delivery nor bit-perfect accuracy
2. Ethernet on its own does not guarantee packet delivery nor packet accuracy nor packet timing
3. USB when used for streaming does not guarantee error-free delivery

I understand why audiophiles who have committed to streaming might react in horror to these assertions.  I urge you to do your own research with an open mind.

There are much better formats than 2-channel PCM, after all!

Ahhh, the power of buffers and asynchronous output.

What I think many are missing is the idea that streamers are not like the phone of old, with effectively one solid circuit between the caller and listener.    There are two separate processes going on at once.  The part that feeds the buffer and the part that doles out the end result.

For pre-recorded media the buffer/bucket can be 30s big or bigger.  The part that gets the stream feeds it into the bucket ahead of time.  The idea is to have enough time that when the TCP/IP stream says "I’m missing packets" or "I have a broken connection" it has time to communicate back to the source and re-request the missing data or start the stream again.  It’s a subtle science here in making the guess as to what the best strategy is to get things going again and when to declare surrender.    If you stream music in your car you have no idea how much your phone is relying on these buffers to get you through the bridge without interruption. 

Here I monitor my Internet access very closely and have failover Internet so when my cable Internet goes away my cellular Internet takes over.  The process takes about 10-20 seconds.  I can tell you that this has happened repeatedly and this has not affected my music.  Of course there are severe Internet events which eventually stop everything but the power of my streamers to driver right over those bumps is a testament to how resilient this whole process is.

While the feeder is busy fixing up the missing data your DAC or TV still has those 30s of data to offer you, so hopefully the stream gets fixed before the bucket is empty. 

We keep talking about noise.  Ethernet is naturally galvanically isolated to a few hundred volts.  It has to be.  Fiber of course is as well.  The bigger issue in my mind are either surges which are high enough to break through that isolation or your Ethernet cables leaking into your AC or interconnects.

Noise in network transmission is not additive.  My router doesn't add noise to the signal from the cable provider.  Any noise is between my router and the next device down.  Reliability is additive, but not noise.  If you have an Ethernet cable capable of 1GigE with no packet loss and no jitter then congratulations, you've done all you can.

The issue that then remains is jitter on the output.  The input and output streams share a buffer and making sure that they do not interfere with each other is another subtle science, which I’m sure is now tackled by a variety of low level libraries available for the particular microprocessor your streamer uses.  I’m not saying they are all equivalent, but that how well your streamer handles this matters. 

My backed-up assertions are

1. Streaming does not guarantee packet delivery nor bit-perfect accuracy
2. Ethernet on its own does not guarantee packet delivery nor packet accuracy nor packet timing
3. USB when used for streaming does not guarantee error-free delivery

At this level, absolutely nothing guarantees error free delivery. This is a straw-man argument where one picks and chooses what they feel is error free or not.

The question is, is it audible?  I'd say no.  What you hear is the quality of the streamer's performance and the original stream.  There are legitimate arguments to be made about any given device's jitter performance or DAC reproduction and that's about all.

So enjoy your cheapie cables. 

Having said this, having heard horror stories of lightning traveling down the cable modem and taking out multiple PCs, TVs and other devices at once without leaving any visible damage I use medical grade Ethernet isolators at the end of long (30') runs. 

@richardbrand 

A person relies extensively on cut-and-pasting at the risk of appearing lazy and unintelligent.

Some highly knowledgeable folks contributed their expertise to this thread, but rather than learning from their expertise you chose to go ask google AI.

Incidentally, as you know, we all have access to google AI and we would know how to query it if we felt like it. Doing it on our behalf adds no value and merely pollutes the thread.

No one can be expected to read 2,000 words of google-generated drivel and I admit I did not - so if I missed something I apologize, but the gist of it seems to be that 100% error-free transmission of a music stream cannot be 100% guaranteed 100% of the time. To which I’m happy to concur: A listener may get caught up in traffic in an underpass and their buffer times out, a submarine may sabotage an underwater backbone cable, etc.

What should be abundantly clear at this point, however, is that music streaming via Tidal and Qobuz, the only kind that matters to audiophiles in this day and age, is error-free absent a rare unrecoverable error; if an unrecoverable error happens, it will manifest in gross failure and playback will stop; and therefore, in no case is a TCP/IP stream or file transfer ever susceptible to the kind of subtle sound quality degradation that strikes fear at the heart of audiophiles. It will either work perfectly - meaning, your streamer will get exactly what Qobuz sent - or not at all.

So it stands to reason that that TCP/IP stream will remain unaffected by components it encounters in the home just like it was unaffected by the components it encountered in the depths of AWS - until it arrives at a component capable of modifying / altering sound quality, aka the streamer.

Router, switches, Ethernet cabling and the like should have zero effect on sound quality (again, all power supplies being equal), and devices claiming to "fix problems" with your home Internet are necessarily making false claims, since there are no problems there to fix.

Happy listening! 

For the application of producing sound, the networks job is to have enough bandwidth to deliver the data needed fast enough so the streamer can stream in real time.   So the network needs to have sufficient bandwidth for the job.  That’s pretty much a given with modern home network technology.  
 

For wireless connections, you have to make sure the wireless connection is strong enough.  Bandwidth will decrease with distance and can become a bottleneck if not done well. 
 

Thrn it’s the streamer and DAC working together to take the data off the network and convert it to sound.  This is where there are lots of possibilities and results can vary widely depending on specific implementations component to component.  
 

The good news is that the technology here is now fairly advanced as well and in practice realized well by many newer products at all price points.