How can different CAT5/6 cables affect sound.


While is is beyond doubt that analog cables affect sound quality and SPDIF, TOSlink and AES/EBU can effect SQ, depending on the buffering and clocking of the DAC, I am at a loss to find an explanation for how different CAT5 cables can affect the sound.

The signals over cat5 are transmitted using the TCP protocol.  This protocol is error correcting, each packet contains a header with a checksum.  If the receiver gets the same checksum then it acknowledges the packet.  If no acknowledgement is received in the timeout interval the sender resends the packet.  Packets may be received out of order and the receiver must correctly sequence the packets.

Thus, unless the cable is hopeless (in which case nothing works) the receiver has an exact copy of the data sent from the sender, AND there is NO timing information associated with TCP. The receiver must then be dependent on its internal clock for timing. 

That is different with SPDIF, clocking data is included in the stream, that is why sources (e.g. high end Aurenders) have very accurate and low jitter OCXO clocks and can sound better then USB connections into DACs with less precise clocks.

Am I missing something as many people hear differences with different patch cords?

retiredaudioguy

Statistically, an Audiophile is more likely to experience a Marian apparition than an Ethernet-related SQ improvement.

 

I was having issues with a consistent WiFi connection so I went with an Ethernet cable from my router to my Innuos Zen MK3 streamer.  I’ve had a great experience with Blue Jeans Cable.  This time was no different.  I ordered a cat 6a cable made to the length I needed. It came with the test report so I knew it was tested.  It sounds great.  No issues dropping the connection.  I didn’t try another cable. Why would I.  I go with what works and don't worry about FOMO.  

I don’t speak from huge experience but you may know from my previous posts here, following much research many seemingly dumb questions asked, I have taken a deep dive into the world of Streaming, finally settling on the Lumin X1.

My direct experience since has been interesting, first I had to overcome the issue of connection my router is in a different part of the home from my Lumin so I had to use the TP Link powerline which to its credit worked first time and provided a stable Ethernet connection. I had a Cat cable not sure if it was a 5 or 6. I think Cat 6 but it was fine to get the Lumin streaming.

Whilst I didn't at first notice any significant noise, I changed after a while to a CAT 8 cable, not for speed or bandwidth, more for noise rejection. My own research had prompted me to try.

Cat6: Typically, unshielded or UTP (Unshielded Twisted Pair), though Cat6a may be shielded.

Cat8: Always fully shielded (usually S/FTP – Shielded Foiled Twisted Pair).

My intention was in one change to reduce or eliminate the possibility of crosstalk and EMI

The result was notable not in the way I had expected. It was more about the move more towards a blacker background that’s how I describe the reduction in noise. It made me speculate that its not about the bits it’s about the removing the interference and maybe crosstalk in non-shielded.

My thoughts moved to perhaps trying the Lumin’s Optical in Via SFP & Optical Fibre input. This intrigued me but I knew it could involve some difficult threading of 20 metres of Optical Fibre back to my router.

I tried short CAT8 cable into a Ethernet to Optical Converter then using a short a High quality/purity optical fiber cable to the Lumin. The logic being complete isolation from noise and the vagaries of ethernet cables.

I have listened to a good few hours using the optical solution and the gains are obvious and positive. I note how music just appears in the sound stage from total quiet, its eerie sometimes but never anything but impressive.

I cannot comment as to the Ethernet vs Optical sound differences except to say noise rejection/isolation definitely gave the optical connection a clear edge.

As to the sound vs analogue. The only comparison I have made recently is the best Royal Scam stream I could find vs the Acoustic Sound UHQR 45rpm Vinyl played via a much-modified Linn LP12 Sondek. I can confirm that it wasn’t really close. The vinyl completely destroyed the streamed version.

So, I am not naive to think that is it Vinyl beats Streaming, I know from other streams that it depends on the quality of the stream vs the quality of the analogue media and the capability of both sets of reproduction hardware but the limited experience has taught me that in this the age of digital that my record player can and does still utterly engage me.

That said the Lumin X1 has opened up a whole new world and way of listening. It can sound astonishingly great and often does.

I now know I have different ways to listen to an appreciate music and that’s the big win here for me.

So the ethernet cable discussion doesn’t really come down to bits, for me it’s more about noise specifically crosstalk and EMI.

I hope sharing my experience so far helps.

This post makes no sense. Who cares how data packets are sent, who cares how usb transmits data. Every cable can sound different or in the case of fiber, no  (noise) at all. If you think only analog cables make a difference, you are missing out.

You don’t think cable types (copper, silver, fiber) can sound different? You don’t think better terminations make a difference?

Forget about how the bits get from the source to your dac, go out and try different cables in your system to see if they make a positive sound quality difference over the cheap Walmart patch cord. When comparing cables, Don’t stop at the cheap Blue Jeans cables, these are low quality cables, get some better cables, the best you can afford and compare them to 1 another. 

@cleeds 

It isn't clear what your claim is here. Qobuz uses TCP/IP - that's standard Internet Protocol. There's nothing unusual about it. It delivers bit-perfect data to your streamer.

I'll try to make my claim a bit clearer. The most important point about digital is that when done properly, extra information is encoded so that errors can be detected and corrected.  The original digital content is preserved no matter how many times it is copied or transmitted, provided the bit error rate does not exceed the maximum correction capability.  

What do I mean by done properly?  I mean that sufficient extra information is encoded to cover all likely error rates. In computer memory, where error rates are low, it is common to provide a capability to detect two bit errors per word, and to detect and correct all single bit errors. 

Much higher error rates were envisaged during the design of Compact Disks, where scratches, fingerprints and other damage had to be taken into account.  The brilliant Reed-Solomon encoding scheme allows up to 4,000 consecutive bit errors to be detected and corrected.

Many people claim to hear differences when streaming music, which are put down to differences in the digital domain.  If digital transmission is bit-perfect, differences can only be in the digital to analogue conversion, or in the analogue domain.  Admittedly, digital devices may inject analogue noise which affects the analogue domain.

Is digital always bit perfect?  Definitely not if I2S is used - I2S does no error checking or correction whatsoever.  Ethernet does check for errors, but on its own does not require packets to be corrected.  And when used in streaming mode, neither does USB.

By the way, TCP is not "Standard" Internet Protocol, it is one of two widely used protocols that run over Internet Protocol, the other being User Datagram Protocol, which was designed to support streaming and does not guarantee bit-perfect delivery.

For some reason people hear internet and think TCP/IP when they could just as easily think UDP/IP.

There are higher-level Internet Protocols such as File Transfer Protocol (FTP) which was modified to run over TCP/IP and returns a bit-perfect file transfer or an error state.

For every packet sent, TCP requires the receiver to send a return message to acknowledge receipt of the packet, and to give the number of the next packet it expects.  The sender can tell when packets go missing, and resend them.  All this can take several seconds and if the packets are being consumed as a stream, lead to dropouts which one might expect to be audible if not totally obvious.

TCP is not bit-prefect if, for example, the network goes down halfway through a stream.  It cannot possibly be.