Surprise findings on Ethernet cables/cleaners/reclockers

[charleski]

Yeah, well it's easy to see where he went wrong.
'The causal connection "Better Ethernet jitter value" = "Better sound" cannot be proven here.'
The equation he needs to assess is instead "More money spent + more fancy boxes littering the living room" = "Lower feeling of inadequacy when browsing audiophool forums".

 

[mcdn]

I've done troubleshooting on large Ethernet/IP networks. It's a mistake to assume end-to-end errors don't exist. A router, for example, rewrites Ethernet headers and recalculates the checksum. I've see routers with slight memory errors corrupt the data field, then create a correct checksum for the packet.

Well yes, me too, for instance an out of spec bit-error-rate on some of a large Telco's kit that was _just_ large enough to cause slowdowns in inter-country data transfers for the bank I worked for at the time.

But that was out of spec by a factor of 1000, and still barely detectable with weeks of engineer time invested. It was also the 1990s. ethernet these days is so good at such a low price it beggars belief. You can put 500 simultaneous stereo 44.1/16 streams over a single consumer 1gbit ethernet connection with perfect fidelity. 50000 over datacenter grade 100gbit connections.

And it all gets buffered into RAM and reclocked out anyway. Even for USB and S/PDIF these days. Bits are indeed bits.

If someone in a hifi shop tells you one device has a better sounding digital output than another, just hold on to your wallet and walk away.

 

[mansr]

Some streaming protocols run over UDP, rather than TCP, where the responsibility for end-to-end data error correction and ordering is the responsibility of the application.

UDP is typically used only in applications where low latency is more important than error-free transfer, such as telephony. Home music streaming invariably uses TCP.

A router, for example, rewrites Ethernet headers and recalculates the checksum. I've see routers with slight memory errors corrupt the data field, then create a correct checksum for the packet.

If such errors are a concern, an application level checksum will detect them. Regardless, a faulty router won't be remedied by a magic audiophile switch.

 

[voodooless]

And it all gets buffered into RAM and reclocked out anyway. Even for USB and S/PDIF these days. Bits are indeed bits.

The amount of software and hardware layers the data travels through from your wifi or ethernet chip to the USB or SPDIF output is truly staggering

 

[fpitas]

I'm staggered that people are cheating audiophiles. When did this start happening?

 

[mansr]

I'm staggered that people are cheating audiophiles. When did this start happening?

Around the same time audiophiles were created, I think.

 

[anotherhobby]

Some streaming protocols run over UDP, rather than TCP, where the responsibility for end-to-end data error correction and ordering is the responsibility of the application. Meanwhile there's a strong move to QUIC and HTTP3.

Can you name a single audio streaming service that applies to this discussion that uses UDP that's not somebody's open source project on github? I'm going to guess there is a zero percent chance of that. UDP is generally used for very low latency where dropped packets are okay (i.e. gaming). UDP is not a good tech for audio streaming, so I'm pretty sure it's not a thing. The discussion of UDP in this case is irrelevant.

I've done troubleshooting on large Ethernet/IP networks. It's a mistake to assume end-to-end errors don't exist. A router, for example, rewrites Ethernet headers and recalculates the checksum. I've see routers with slight memory errors corrupt the data field, then create a correct checksum for the packet.

So have I. I've been in this industry for over 30 years. That's a bad/broken router. That's a very specific problem in a very specific circumstance, and your stream would stop working or rebuffer if that happened, but you would not lose "audio quality." If TCP did not work the way it did, the Internet literally would not work. TCP guarantees you either get all the stream's contents in the correct order, or not at all (an error). A broken router is irrelevant in the context of this discussion.

However, everything I've seen so far in audiophile land to "fix" Ethernet is daft.

Agree since there is literally nothing at all wrong and there is nothing to fix.

Some equipment may not have good galvanic isolation, or may be sensitive to noise, but those are flaws which should be fixed, not mitigated.

Agree, and again not relevant to the actual claim, as there is zero validity in the base claim.

I don't mean to be argumentative, I just don't think this claim deserves any help whatsoever.

 

[pkane]

Around the same time audiophiles were created, I think.

It's a self-reinforcing loop: audiophiles "hear" a difference, speculate as to what causes it, then some go into business to manufacture devices believing that they discovered something new. The audiophile press starts reviewing them, audiophiles read about them, buy the products and post exuberant reviews.

New audiophile businesses spring up, encouraged by the press and the growing audiophile interest, along with overly positive forum and web "reviewers". Old, established business see a high profit market, and join the fray. They experiment with tweaks without understanding of physical or psychological principles behind what they (or their customers) hear, and the loop closes with more and more expensive products being created based on nothing but speculation and uncontrolled listening tests.

I'm sure that a few audiophile tweak manufacturers are lying and know better. I bet most are just as deluded as the rest of audiophile community and are simply not interested in learning the truth.

 

[sq225917]

I'm staggered that people are cheating audiophiles. When did this start happening?

Im in hospital with two broken ankles and I just sprayed tea all over my bed and phone.

 

[mansr]

Im in hospital with two broken ankles

I told you to be careful about pissing off Ted Denney.

 

[Grumpish]

Anyone honestly believing that certain Ethernet cables, audiophile grade switches, Ethernet reclockers, and so on, can make an improvement either doesn't have a clue how TCP/IP and Ethernet work or started out with faulty kit.

 

[fpitas]

Anyone honestly believing that certain Ethernet cables, audiophile grade switches, Ethernet reclockers, and so on, can make an improvement either doesn't have a clue how TCP/IP and Ethernet work or started out with faulty kit.

While I have to agree, in the context of audiophile tweaks, it's really no worse than cable risers, the Shakti Hallograph and numerous other magical implements. They are all a way of improving PRaT and separating a prat from his money.

 

[Peterinvan]

Literally all anybody needs to do to debunk these types of clamis is to take a few minutes to actually read the wikipedia page on TCP. That's it! It debunks all of it simply by the nature of how TCP works (and you can apply what you've learned to more than stupid audiophile myths). I mean, this paragraph alone drives a nail right thru it (my bolding for emphasis):

In other words, TCP fully reassembles all the packets BIT PERFECT (to use an audiophile term) to what came over the "wire" before any audio application ever sees it. If you are using TCP, the layers below it do not matter at all as long as the packets are coming in fast enough.

does this apply to streaming data as well?? I did not think there was any “re-sending” of streaming packets??

 

[blueone]

Some streaming protocols run over UDP, rather than TCP, where the responsibility for end-to-end data error correction and ordering is the responsibility of the application. Meanwhile there's a strong move to QUIC and HTTP3.

QUIC is targeted at cloud data centers, and is primarily about reducing connection establishment time and improving congestion management. It is also one of several protocols which is encapsulated in UDP because of the ridiculous intellectual property rights control of the IETF, but I digress. For home Ethernet networks none of this stuff matters.

I've done troubleshooting on large Ethernet/IP networks. It's a mistake to assume end-to-end errors don't exist. A router, for example, rewrites Ethernet headers and recalculates the checksum. I've see routers with slight memory errors corrupt the data field, then create a correct checksum for the packet.

However, everything I've seen so far in audiophile land to "fix" Ethernet is daft.

Some equipment may not have good galvanic isolation, or may be sensitive to noise, but those are flaws which should be fixed, not mitigated.

When we consider that a typical wired Ethernet network in a large home consists of an Ethernet line going from the cable modem to one to three second-level Ethernet switches - usually 1GbE - and the cascade depth of the network is two, and these switches are typically (almost always) using old-fashioned IEEE 802.1 bridging (i.e. Spanning Tree Protocol), this is not high-tech stuff in the modern sense. And even 1GbE is serious overkill for audio (uncompressed 24/192K digital audio requires - what? - about 10Mb/sec per stream).

I was recently having a casual conversation with a custom HT installer, and he told me that most of the new homes he's outfitting are not being wired for Ethernet, but for WiFi 6 meshes, even homes with a 4K TV in several rooms. He did do one home recently wired for 10GbE, but that was an outlier. Wired Ethernet is apparently so yesterday.

 

[MaxwellsEq]

Can you name a single audio streaming service that applies to this discussion that uses UDP that's not somebody's open source project on github? I'm going to guess there is a zero percent chance of that. UDP is generally used for very low latency where dropped packets are okay (i.e. gaming). UDP is not a good tech for audio streaming, so I'm pretty sure it's not a thing. The discussion of UDP in this case is irrelevant.

Some professional studio video and audio protocols are based on UDP. Domestic audio streaming protocols are TCP, but QUIC may change that:- there are reductions in server and multiplexing overhead which the stream providers may benefit from. Also reducing the delay to your home (e.g. for Radio and TV streams) is a goal of providers, so that you don't see the World Cup goal 20 seconds after your neighbours have been cheering when watching via DTT. https://fiestajetsam.github.io/draf...rements/draft-gruessing-moq-requirements.html

So have I. I've been in this industry for over 30 years. That's a bad/broken router. That's a very specific problem in a very specific circumstance, and your stream would stop working or rebuffer if that happened, but you would not lose "audio quality." If TCP did not work the way it did, the Internet literally would not work. TCP guarantees you either get all the stream's contents in the correct order, or not at all (an error). A broken router is irrelevant in the context of this discussion.

You are right it was a broken router. But the error occurred once every million frames or so! The only way I could find what was going on was by correlating card data and netstat over a bunch of devices, some routed through it and some not - the Ethernet errors were lower than they should have been relative to IP/UDP and IP/TCP. TCP/IP-based systems silently recovered from the junk they were given, but some UDP-based systems were confused. Once I caught a corrupted packet it was clearly rubbish, but the Ethernet checksum was correct!

Agree since there is literally nothing at all wrong and there is nothing to fix.
Agree, and again not relevant to the actual claim, as there is zero validity in the base claim.
I don't mean to be argumentative, I just don't think this claim deserves any help whatsoever.

I'm not in any way supporting the claims by these vendors.

 

[voodooless]

but QUIC may change that

It changes nothing. It’s still a reliable protocol, just as TCP is. It only happens to use UDP because it’s low level enough to build upon, and has good enough legacy support to work
well with all kinds of stuff easily.

 

[KSTR]

@all,
sure, bits are bits, data integrity is not affected as it is guaranteed by design of the protocols used. That is not the point here.

The point here is that at the last stage of the digital stream, at the input of the DAC chip proper, noise and timing issues might affect analog output (which is certainly true for bad DAC designs), also the noise can sneak directly into the analog circuitry. And that's why less noise and better timing right at the DAC input can make a difference if better cables or whatever do actually achieve that... as I said before, this is not so easy to examine (measure) but it is not impossible and thus cannot be dismissed by philosophical arguments (like "bits are bits"). But, alas, this is not what's been tested by Eric, rather he tested for potential disturbing mechanisms which may or may not affect the analog output.

 

[blueone]

@all,
sure, bits are bits, data integrity is not affected as it is guaranteed by design of the protocols used. That is not the point here.

The point here is that at the last stage of the digital stream, at the input of the DAC chip proper, noise and timing issues might affect analog output (which is certainly true for bad DAC designs), also the noise can sneak directly into the analog circuitry. And that's why less noise and better timing right at the DAC input can make a difference if better cables or whatever do actually achieve that... as I said before, this is not so easy to examine (measure) but it is not impossible and thus cannot be dismissed by philosophical arguments (like "bits are bits"). But, alas, this is not what's been tested by Eric, rather he tested for potential disturbing mechanisms which may or may not affect the analog output.

You're forgetting about end station buffering. Every audio streaming app I've tried (several, including Apple, Amazon, Spotify, etc.) buffer at least two seconds of audio. All of the effects you're discussing will be negated by buffering.

 

[sq225917]

I told you to be careful about pissing off Ted Denney.

It's the cable mafia what done for me, I should have taken their threats seriously...

They're watching.

 

[12Many]

Interesting to me that, once again, adding low level noise seems to be correlated with finding the sound "more spacious". In this case, unlike vinyl/tape/tubes, it may not be audible.

That statement caught my eye. We as humans have a sense of what sound 'sounds like' in a spacious room so by modifying the signal (introducing some type of distortion) to have that same effect, it would be interpreted by the brain as making the sound seem spacious, although likely less accurate. People may prefer this, even calling it an improvement, even though it may be some type of distortion or noise. I recall an older AV receiver I had that had different room effects to make it sound like different rooms: outside, jazz club, church, stadium - I think they were using digital filters to adjust (distort) the sound to give a similar effect.