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

Anyone who holds the mistaken belief that cables supporting TCP transmissions, routers, network switches and the like can make a difference in sound quality should be required to read the following before opining further:

http://units.folder101.com/cisco/sem1/Notes/ch7-technologies/encoding.htm

Followers of the "all-digital-is-analog" superstitions won’t likely read past the first page, so the TLDR is that TCP protocols guarantee error-free data delivery regardless of the vector on which it’s transmitted, thereby effectively abstracting the physical layer.

That said, copper cables transmitting TCP can indirectly affect sound quality by hosting parasitic noise. As others have confirmed, this is easily solved by using SFP (fiber) in the last run of cabling going into your streamer. This prevents any ground noise from reaching your system by galvanically isolating it (fiber is non-metallic, therefore non-conductive, therefore it does not pick up or transmit EMI or RFI).

Best practice is to keep all Ethernet gear in a utility closet / room at a remove from the listening room, wall warts and SMPS-powered computers and what not included (keep them on a separate AC circuit from your system), and run SFP fiber from your switch to your streamer. This way what happens in the utility room stays in the utility room, and inky black noise floors are yours.

 

Post removed 

On the issue of networks and their impact on sound quality. Those approaching this from the science perspective, prima facie argument precludes yielding any validity to those reporting networks do indeed impact sound quality. Ignoring this and reverting to prima facie arguments is not good science. Quality scientific inquiry requires addressing  this counter argument through development of more rigorous research into the possible causes for this variability. Simply writing off this evidence as some derangement syndrome, based on emotions and/or distrust of human senses doesn't pass muster. 

 

Instead of retreating to the same old refrains, try to find explanations for why individuals hear differences with a multitude of audio streaming devices. Another option is to actually experience these devices in your own streaming chain.

Instead of retreating to the same old refrains, try to find explanations for why individuals hear differences with a multitude of audio streaming devices.

@sns 

In many instances, those differences are heard in systems that are not galvanically isolated behind at least one run of SFP fiber.

When differences are still heard with components or cables located upstream of fiber isolation, explanations still exist for that phenomenon, to the extent that psychology is indeed a science.

 

Galvanic isolation in quality streaming components is virtually a given these days, certainly there are generic streaming components lacking this, and I do agree this needs to be addressed.