I use a RME DAC in my setup, and one of the things I like about it is the Bit Test feature. RME supply the WAV bit test files on their site. I've converted them to FLAC. The DAC shows up a message on the LCD when the bit test (played on repeat) is matched perfectly. So no stuck bits, missing bits, bit flips.. just the correct sequence repeated over and over again.

My FLAC files live on a SSD attached to a Raspberry Pi that serves them up over NFS. The data passes through three gigabit switches before arriving at another Raspberry Pi running Volumio, which is connected to my DAC.

There's enough there to keep an audiophile awake at night, but the bit tests have passed perfectly whenever I've run them. No expensive cables, linear mode power supplies, or audiophile switches would make the tests pass any better.

Well, when they're claiming to hear different versions of memcpy, I can't imagine the bits coming across the same is enough for them.

Im assuming you're using sata over usb for the ssd; that latency hoop alone would give nightmares to some audiophiles :) kudos for having a true hifi system without buying into the bullshit

TCP preserves the order.

By retransmitting. Packet loss causes stalls and if there's insufficient buffering, that's an audio glitch.

A patch cable or its connectors would need to be in a dreadful state to get packet loss though, i.e. physically damaged or defective.

Back of napkin estimates:

For lossless CD-quality audio you need about 160kbyte/s.

So on a gigabit network (125Mbyte/s), you'd need over 99.999% packet loss in order to not keep up.

So they're comparing to an almost completely faulty cable.

I feel like a lot of audiophile stupidity is not understanding scale.

There is a difference between the fancy speaker cables and acceptable cheap ones, but it's so ridiculously minuscule as to be completely inaudible compared to, say, whether or not the listener is wearing socks or not.

The only real difference between the cables will be at frequencies over, say, a GHz. ie RF frequencies 50x higher than cats might be able to hear.

But the audiofool will say, "see, there's a difference - I want my system to sound the best".

And they focus so much on ridiculously overkill cables, amplifiers and stands, yet seem to often ignore room treatment which could really make a difference. It's often massive speakers in horribly reflective minimalistic rooms, driven by amps running at 1% of their power rating.

As someome pointed out, even 99% packet loss on a modern network wont affect the stream. I've actually seen (unfortunely) 100mbit "working" with cat3 (phone) ribbon cable... For short distances (<10m), it wont even reach 10% packet loss. And players buffer. Always.

Parent is talking about timing, I assume?

But that is a correctness issue (to the end user), not a quality issue. Wouldn't that cause lag/pauses, or other errors when playing in real time?

That would be correct if things went this way:

Storage -> TCP Stream -> Sound output.

However, it never works like this, except maybe in some rare live conditions (in which case, why are you even running this on TCP?). In reality, it goes:

Storage -> TCP Stream -> Ring buffer -> Sound output

Unless you manage to empty your ring buffer (which, in the case of modern hardware can easily be 32+MB, or multiple seconds of audio), you will not hear a single bit of difference. And if you do, it won't come in "after you were meant to hear it", you'll either get a massive gap, or repeats. There is no such thing as "data coming in too late/out of order".

Audio is rated at kilobits a second while modern networking equipment is rated at gigabits a second. So your networking equipment is multiple orders of magnitude faster than your audio file streaming speed.

If you’re getting audible errors from your network then literally everything you do on that network would feel like 90s dial up days and with lots of corruption. Most websites wouldn’t even load due to TLS errors.

The problem such arguments as yours is that people have subjective experiences that can be influenced by a multitude of personal emotional states and they then retrofit pseudo-technical explanations for why they perceived those experiences. Or in layman’s terms, you basically just buy an expensive placebo.

I aggree the placebo effect is a huge problem. I am not suggesting expensive solutions, I am just saying check your physical installation and maybe not the very cheepest hardware off AliExpress.

The are lots usecases for nearly live audio where TCP stalls cause problems you would never notice browsing the web and would not be a TLS error (which is ushally how networks are 'tested' leaving the problems unfixed).

Live is a very different problem to home listening. Live requires near real time playback on content that is generated in real time. Whereas for any kind of pre-recorded performance, such as listening to music at home, you can read ahead and buffer. So the issues you present simply don’t exist in home set ups.

And before you comment about listening to live performances at home: the broadcaster would be compressing your audio stream anyway. That would be far more impactful to your audio quality than a few dropped networking packets.

Source: I used to work in broadcasting.