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

@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.

 

 

richardbrand

... By the way, TCP is not "Standard" Internet Protocol, it is one of two widely used protocols ...

There are many internet protocols. TCP/IP - which is the protocol used by services such as Qobuz and Tidal - deliver bit perfect data to your streamer. It is as simple as that. I’m not sure why you use so many words to claim something different.

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 ...

That would suggest a problem with the network. As everyone knows, the stream is fed into a buffer and many minutes of music can be sent, verified as bit perfect accurate, and stored in the buffer in a matter of seconds. Literally. So even a pretty wonky network is capable of delivering bit-perfect data to your streamer pretty much every single time.

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

What’s your point? A CD player with a broken laser won’t work. A turntable with a fried motor won’t work. A car with no gasoline won’t work. Broken things don’t work.

In most networks you are receiving all of the data and it is bit perfect. And if your service is using TCP, not IP, then it is for sure bit perfect. But that is not the big issue, noise is the big issue. If CAT 6 offered perfect shielding, then there wouldn’t be CAT 8. My system sounded great with a 30’ BJC cable, until I replaced it with optical. You don’t notice the noise until it’s gone, and thus begins your cable journey. 

If noise, picked up by non-shielded Cat5 cables is the problem, and from responses it seems that is might well be the issue, would that argue that a Wi-Fi (and thus decoupled) connection would work best?

I cannot personally comment on this as I rarely listen to streaming sources on my big rig (I hate to say reference system) and it does not support Wi-Fi anyway, and my 2nd system has only Wi-Fi capability.

My wife is a wonderful supporter of my high end journey (she supported my upgrade from a K-01xs to the xd) but would probably be critical of a 30 foot cable draped around the room from my WAP/Switch to the Bluesound node - but I might try it one day when she is out at the gym as I have a Cat5 cable building kit. 

The actual transfer of the bits seems unlikely to be the issue as the highest bit rate for streaming would appear to be 18.423 Mbps  (2*192k*24*2) (two channels*sample rate*bit depth*2 for the TCP and other overhead) and the Cat5 standard is for 100Mbps.