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?
I think that the consensus is that the sonic differences are caused, not by digital issues, but by RFI or other noise induced in the patch cord leaking through into the analog circuitry.
Perhaps I am lucky (or hard of hearing) but yesterday I listened back to back to the Weilerstein Elgar from my Aurender SSD, USB connected to the Esoteric K-01XD SE and the same work streamed from Presto through the Bluesound Vault, TOSlinked to the DAC and detected no differences. I live in the country, and my system is located far from any in-home electrical or electronic devices. Also, the Esoteric unit is engineered to separate analog and digital processing.
My streaming is limited by drop-out in my internet connection.
@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. ;-)
@richardbrandThe 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.
@hermanMy first post on this thread mentioned the endless repetition of the same old tired refrains on this subject, and then I get involved yet again. I will try to remember this and simply tune out next time.
Tedious as these threads are (here we agree), they exist because some folks keep spouting nonsense, rooted in ignorance and false superstition, as fact.
Come to think of it... Oh, never mind.
Until these folks either start educating themselves or stop posting, I am afraid these discussions will continue, even if, like you, I’d rather they didn’t.
@toyman+1 I tried about a half dozen ethernet cables before settling on the Sablon Audio 2020. In my system, it was pretty easy to hear the improvement in SQ. Better tone, timbre, dynamics. More articulate. I have two in my streaming chain.
I laugh at some of the discussions on this forum. I can tell the difference between DACs, Preamplifers, power amplifiers, speakers, and speaker cable, interconnects between sources which can be quite apparent. With the discussions about Ethernet switch and Ethernet cable quality it's a wonder why my system doesn't sound like a transistor radio, or at best, an off shelf all in one chepo.
I am very critical of my stereo sound. But can accept budget restraints and push as much quality as I can for my dollars spent.
I have been an information technology pro for 35 yrs, before that an electronics tech which has nothing to do with my ears.
I cannot imagine my system sounding better for my money spent. I use a cheap $35 Ethernet switch over a 100mb/s network. Comcast claims audio takes only 5mbs streaming. ??? I have been at the brick and mortor show rooms and in that heaven, listened to systems 5 times the cost of mine. Did they sound better, well yes in some ways, but not in others. Was there enough difference in quality for me to upgrade to the next level. Nope!
To sum it up, My picky ears which caused me to be critical about my sound is perfectly happy with the cheapo LAN, and Ethernet switch and I would be hard pressed to change anything. I completely enjoy the streamers connected to that cheapo Netgear $35 switch and it kicks booty. Laugh if you want, but I laugh to the bank and from what I am hearing, it's great.
Each new debate of this topic brings new perspectives and experience with new configurations and equipment, I find it useful and entertaining.
As a retired software engineer who worked on operating systems and used lots of protocols over the years, I understand well the argument from that side of the fence. However, empirical evidence, listening to different configurations, has confirmed for me that the last run to the streamer makes a difference in my environment, and for very little cost.
@foggyus91Good choice in cables, I prefer silver for digital, but not for analog. OCC for everything. I use a similar cable, probably Neotech underneath:
In playback (like a DAC converting to analog): jitter can smear the timing of the reconstructed waveform, producing subtle distortion or loss of clarity.
There is an important difference between digital music files and other computer data files. This would be time domain errors rather than the absolute correctness of the data file. With music files, there is less time to correct errors during the process of converting digital music files into analog sound waves. As other have mentioned, there is nothing wrong with the music file data; the differences are in the timing of when a binary 1 becomes a binary 0 versus when that should actually happen based on the original recording. There is probably a valid debate as to whether those differences are audible & probably a debate as to whether some people can hear those errors and other people cannot.
My real-world experience listening to ethernet cables including an AmazonBasics Cat 6 cable, Supra Cat 8 cable, and a ethernet cable from a Chinese company via Amazon is that all sounded different.
What I have heard from the Supra cable versus the AmazonBasics cable is:
- More presence to voices and instruments which sound more forward and distinct in presentation
- Richer tonality
- Less grain to the sound
- Better resolution due to a lower noise floor (This is audible when comparing a cleaner signal to one that is less clean)
- Easier to follow bass lines
- Pace seems faster due to more clarity and better definition to the leading edge of notes.
In terms of potential bias in my listening, the Supra cable was something that I could return at no cost. I was interested in hearing:
1. Whether there was an audible difference?
2. The magnitude of that audible difference?
3. Whether that audible difference was worth the $60 that changing to the Supra Cat 8 ethernet cable would cost me versus sticking with the $8 AmazonBasics cable.
@calvinandhobbes The theory that jitter 'smears' the timing thus 'producing subtle distortion or loss of clarity' is not supported by the actuality of how the USB connection actually operates. S/PDIF connections, fiber or coax, operate under similar mechanisms and error rates as USB. If your DAC is connected to your streamer via USB, then USB Isochronous Transfer Mode is used with CRC only, not full error checking. But looking deeper that's not really much of an issue. So bear with me, here's what that means.
At the physical layer (PHY), USB 3.2 allows a BER (bit error rate) is 1 bit in 10^12 bits. (1 bit per 1.2 GBytes) This high level of reliability and performance is due to the involvement of several components - the transmitting PHY media: receptacles, cables, and the receiving end. The USB 3.2 specification has built-in protections against bit errors, such as redundancy in packet framing and link commands, along with CRC for detecting multiple bit errors. The error recovery process, which can be hardware or software-driven, kicks in upon detection of integrity issues.
When errors are detected, the hardware or software initiates a re-transmission request, with the host controller repeating this up to three times. Further errors and retries can reduce overall throughput, but a well-designed receiving PHY layer can mitigate this by cleaning up issues and reducing error rates.
At the link layer, within the digital logic of the controller, the BER expectation is even greater: 1 bit in 10^20 bits (1 bit in every 50 million Terabytes). Once the data is in the silicon, errors are minimal. However, if an error is detected, the controller attempts up to three retries.
Isochronous transfers, used for streaming, can afford to lose packets as the next frame of data is always prioritized. But that is exceedingly rare - on the order of one bit every 107 hours hours of 24-bit 192K. This would include any jitter-induced errors. Jitter-induced errors, when they occur would trigger a CRC (cyclic redundancy check) error, and a retry,
The theory that jitter 'smears' the timing thus 'producing subtle distortion or loss of clarity' is not supported by the actuality of how the USB connection actually operates. S/PDIF connections, fiber or coax, operate under similar mechanisms and error rates as USB.
@calvinandhobbesNo, recovery is not instantaneous, nor does it need to be. The incoming packets are stored in a buffer then released when the error-checking/correction is complete. This is a continual ongoing process measured in milliseconds, and the buffers are sized to accommodate almost any conceivable requirement or packet loss short of a complete failure, so unless there is a calamitous event, the entire process is transparent and the buffer output is seen as continual.
TCP/IP does exactly the same thing, independent of the physical media or wireless transport.
You must have a verified phone number and physical address in order to post in the Audiogon Forums. Please return to Audiogon.com and complete this step. If you have any questions please contact Support.
