1. Home
  2. cables
  3. 195218-198226

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
retiredaudioguy OP
290 posts
 

My point is actually stronger than TCP being error free, it is that the submission of the buffered data to the DAC chips is totally isolated from the nature of the patch cords.  The data is stored in a RAM buffer and is fed to the DAC circuits by a clock in the DAC, so I am a loss as to what is causing people to hear sonic differences.

I just did an experiment, I started PRESTO streaming through my entry level Bluesound device which is wired to my LAN.  After playing the stream for a few minutes  - I pulled the LAN cable from the Bluesound node.  The music continued for perhaps 20 seconds.  The streamer is buffering about 20 seconds worth of bits, I tested that it is the streamer by repeating the exercise but pulled the TOSLink, there was an almost immediate cessation of music.  

 

retiredaudioguy OP
290 posts
 

OOPS.  Thanks Richard brand.  Streamers usually use UDP which does not have error correction, so a really bad patch cord could cause data errors.

cleeds
6,582 posts
 
retiredaudioguy 

Streamers usually use UDP which does not have error correction, so a really bad patch cord could cause data errors.

That's a pretty broad statement and not all streaming services work the same. Netflix, for example, is a different scenario than Qobuz or Tidal.

In the case of the audio-oriented services such as Qobuz and Tidal - they use TCP/IP and you are getting bit-perfect data delivered to your streamer's input.

richardbrand

... streaming requires a near constant stream of packets ...

Oh no, not at all, at least not when we're talking about the limited bandwidth needed for audio. On my network, my streamer will load minutes worth of hi-res music into its buffer in a matter of seconds. That is easy to test.

emergingsoul
1,536 posts
 

Better shielding.  That stands out as the biggest improvement. Data capacity is not the issue. Unless it's a video

panzrwagn's avatar
panzrwagn
692 posts
 

"I don't pretend to understand the science." Perhaps the understatement and flag banner of this century. 

Whatever differences people are hearing have nothing whatsoever to do with what happens at the transport layers. They are trying to.apply analog issues and parameters in the digital domain, a complete non-sequitur. 

TCP/IP guarantees bit perfect delivery 100% of the time. All 'streaming' done withe TCP/IP is buffered multiple times b

More to discover