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 4 responses by panzrwagn

"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

@richardbrand Switched  Ethernet typically does not use CSMA/CD (Carrier Sense Multiple Access with Collision Detection) for its primary operation. While CSMA/CD is a fundamental part of Ethernet technology and was essential for early Ethernet networks using hubs, it is obsolete in modern switched Ethernet environments. 

TCP/IP guarantees bit perfect delivery. Packet sequencing, checksum and other header data answer the remaining questions about dropped, deformed or other anomalous packet behavior. When i was first introduced to TCP/iP in the late 1980s I was overwhelmed at everything the protocol did compared to competing non-routeable protocols like NetBEUI and IPX, but it became very clrar very shortly that TCP/IP was the future.

When Microsoft made its big push into networking, it threw tons of money into free training for Microsoft Certified Systems Engineers. And the class that separated those who would make it and those who couldn't? TCP/IP.  I took the week long class in LA - MS flew me from Seattle, housed, and fed me on their dime - with the provisions that if you failed, you wouldn't get reimbursed until you passed. Highly motivational. We had over 20 people in that class and about half failed the exam on their first try. It was a tough class, their toughest, and luckily I passed and became MCSE #410. There are now tens if not hundreds of thousand MCSEs.

A few years later Cisco Systems created the Cisco Certified Network Engineer, a curriculum so challenging that one CCNE i knew said "Next time I'll do something easy, like medical school." He wasn't kidding. So I went into Systems Architecture instead, and the CCNEs essentially worked for me. I knew the network architecture and dealt with big picture stuff , budgets, and management, shielding the CCNEs so the could concentrate on building and operating a 5-9s global infrastructure with multiple Enterprise-class data centers.

But boil it all down, and Switched/Routed Ethernet and TCP/IP is at the heart of networking as we know it today. I still like getting my hands dirty, I pull my own cable, terminate all my own connectors, and am even a certified fiber splicer. And I am very confident about what networking can and cannot add or subtract to sound quality.

So I'll say it again, whatever SQ differences people think they hear, it has nothing to do with anything happening at Layer 1 Physical, Layer 2 DataLink, or Layer 3 Network Layer 4 Transport, Layer 5 Session, Layer 6 Presentatio or Layer 7 Application. Or the condensed and simplified 4-Layer model. It is all happening above that. The entire DAC process rides above all the networking, and the analog output simply isn't even in the same domain.

@jea48 I depended on Fluke gear for years and even did some consulting on the original LanMeter. We even suggested "If it works, it's a Fluke" for an advertising slogan, but Marketing wasn't amused. I still think it was a lost opportunity. 

@retiredaudioguy. I am confident there are those who claim to here the differences between 568 A and B. Im equally confident they will hear differences between 568 A and 568A as in your first post. 

@oberoniaomnia  Oooh, there you go getting all logical and facty again. ;-)

@richardbrand The network failure you describe would drop any non-validated packet data received and request a resend until either a correct packet is received or the process times out. The last complete CRC error-checked and packet acknowledged is the last valid data. 

The sequence number is the byte number of the first byte of data in the TCP packet sent (also called a TCP segment). The acknowledgement number is the sequence number of the next byte the receiver expects to receive. One more TCP feature that ensures data quality.

When the missing packet arrives, TCP can reorder the packets based on their sequence numbers before delivering them to the application layer.

I'll stop here, but the more you study TCP, the absolute brilliance of it becomes more and more apparent.Remember, the idea was to literally have a bomb-proof network. 

J