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

Showing 3 responses by cleeds

cleeds
6,258 posts
 

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.

cleeds
6,258 posts
 

richardbrand

Qobuz seems to implement a sort of "running" TCP/IP which is bit-perfect for the completed packets already received, but who knows what the internet will regurgitate in the future?

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. Whatever shortcomings you might detect with audio streaming, you can be sure the data you're getting from sources such as Qobuz and Tidal are - literally - bit perfect.

cleeds
6,258 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.

More to discover