The Shunyata Research OMEGA-X-Ethernet Cable

I will attempt to summarize facts from a quality engineering perspective:

1.  Data packets are transmitted as differential electrical signals.  Therefore, an Ethernet cable is a wire connecting a modem to a streamer (unless you have an optical connection).  
2. Standard data transmission and receipt protocols assure data is bit perfect; therefore, incorrect data packets are remote, or corrected.  Think of the potential collapse of global financial systems is this is not the case. 
3. Considering that an Ethernet cable (or any digital cable like a USB cable between the streamer and DAC) carries an electrical signal connecting a modem to a streamer, any cables can alter RFI noise coupling, and the resulting interference of electrical environment of a streamer or DAC are physically plausible.  Therefore, the design of the conductor and shielding is critical to reducing the probability of RFI noise from entering the system.  
4. If the electrical current carrying the data package carries RF, RF energy can couple into chassis grounds, power supplies, clocks, or analog circuitry.

The quality of an Ethernet cable affecting sound quality is physically plausible.  Everything is simply physics.  We can debate the degree of the affect and benefit / cost ratio of an expensive cable ad nauseam.  
 

From my experience, when I purchased my first streamer I purchased an audiophile grade Ethernet cable that cost $500.  I was hearing hi-frequency noise.  I contacted Aurender.  They stated my cable had metal connector housings and stated to go with a good cable that plastic connector housings to prevent RFI.  The recommended a $50 Blue Jeans cable.  Problem solved.  My experience is that the design and quality can affect sound quality due to the design and quality from the perspective it is an electrical connection.  The affect on sound quality has nothing to do with data package transfer since transmission/reception protocol assure bit perfect transfers.  

@jsalerno277 

Standard data transmission and receipt protocols assure data is bit perfect; therefore, incorrect data packets are remote, or corrected.  Think of the potential collapse of global financial systems is this is not the case. 

Financial institutions can usually (not always) withstand retransmissions.

For example, I used to manage a Thomson Reuters market data business unit.  We sent out "ticker" to our customers.  That ticker was "real time".  But there were times when a symbol was missed, due to a packet loss, and some of the customers were not happy.  The retransmissions were immediate, but immediate was too late.  And we had to get our leased lines checked.

Whereas, if I do a Venmo transfer, it makes no difference if packets are lost, and re-sent, and it takes 1/100th of a second more to complete the transaction.

The affect on sound quality has nothing to do with data package transfer since transmission/reception protocol assure bit perfect transfers.  

With audio, it is more than the bits eventually getting there in their entirety.  It is about the uncanny accuracy of those bits, and for the bits to be in timed order.  Anything less results in jitter.

I am not an expert on which devices need to be perfectly timed, where re-transmissions are ether pointless or taboo.  But the device feeding the DAC needs to be perfectly timed.  If that is an Ethernet cable that is feeding the DAC, then TCP/IP error correction protocols will not help.

I do not use an Ethernet cable to feed my DAC.  I have no experience in swapping Ethernet cables for that purpose in the data chain.  But I have heard improvements with quality USB cables and quality AES/EBU cables.  So I am open to the notion that quality Ethernet cables might be beneficial, too.

And the design quality has to be audio centric, as you discovered.  That cable that you had issues with would likely work perfectly on a router or switch, for general data transfers.

I am only familiar with quality engineering principles for medical devices and for audio (music files).  Let’s stay with music files.  Protocols, including the Red Book Standard, UPnP, UDP, TCP/IP uses cyclic redundancy checks and imbedded check code sequences to assure data is not corrupted or lost.  The equipment buffers the data packages and performs redundancy checks to assure bit perfect files.  I am not familiar with your example where there was immediate data transfer without benefit of redundancy checks.  
 

We agree that audio is not only about bit perfect data packet transfer since transmission. The Ethernet protocols, and rugged digital audio protocols above only assure accurate transfer including sequencing. These protocols use packet  switching and stacking.  Each packet is timestamped and reassembled.  The timing critical to sound reproduction that produces jitter is a continuous conversion of digital data to analog.  This is handled by streamer, DAC, or external clocks after the Ethernet cable in the system circuit.  So, I do not believe the Ethernet cable has a direct effect on jitter.  Rather, if not shielded, it can have an indirect effect by RF coupling that can affect streamer and DAC clock performance, and produce RFI distortion in the analogue signal as I experienced.  

@jsalerno277 

The equipment buffers the data packages and performs redundancy checks to assure bit perfect files.

The sending device cannot know if there was an issue with the receiving device, unless the receiving device informs the sending device.  That is where timing issues for a DAC will surface, either with gaps in the data stream, or out-of-order packets (which is not a problem for downloading your bank statement, because as long as all of the packets eventually arrive, the computer knows how to assemble the file).  But when a DAC is playing the bits, in real time, as they arrive, problems with packets will result in jitter.

Some DAC boxes do buffering (not the actual DAC, but a chip under the same hood).  That buffering chip is now acting as a transport and clocking the bits that it is feeding to the DAC.  So under those conditions, lost packets / retransmissions will not matter (well, as long at the drops are not severe).

But DACs that do just their purpose-built function, and leave the transport business to a digital-to-digital converter (DDC) or to a streamer, then bit-perfect timing from the sending device becomes critical.

Whatever the last chip is that connects to actual DAC chip is critical for timing.  If it is a buffering chip, then it is the critical chip doing the transporting of the bits to the DAC.

Rather, if not shielded...

Yes.  True for all cables.

When it comes to a stereo sounding wonderful, there are numerous levels of wonderful.

My DAC sounded wonderful, until I added a DDC into the data chain, and had the DDC feed my DAC the bits.  The DDC uses two, ultra precise clocks (one for 44,100 Hz and its multiples, and one for 48,000 Hz and its multiples).

With the DDC feeding my DAC a less jittery bit stream (jitter I never heard), I reached a new level of wonderful, due to less jitter.  Now I can hear the jitter that I had previously never heard (or never recognized).  If I remove my DDC, I hear the jitter.  If I had never inserted that DDC, I never would have heard the jitter.

You purchased a $500 Ethernet cable that was not suited for audio.  Perhaps one that is suited for audio will get you to a new level of wonderful, more so than your very good Blue Jeans cable?  No way to know until you try.  That is how I found out with my system.

@seymour-krelborn 

The OP focus is on the network Ethernet cable.  You are focusing on the DAC.  

We agree data packets transmitted over the Ethernet can be corrupted.  The bits travel on an electric current and any electrical anomaly can cause corruption. Think of streaming television where, in an electrical disturbance you can have screen dropouts.  
 

What I continue to stress is that Ethernet protocols are robust with built-in error detection such as CRC (Cyclic Redundancy Check) and imbedded check code sequences that flag an error. The Ethernet protocol will simply request that packet again.  Streamers and DACs do no rely on corrupted packets;  rather, they buffer until  a correct, complete packet is received.  So, in a well-functioning network, you won’t hear sound quality issues because the data is either correct or it’s re-requested, unless the buffer is too small or network latency is extreme, where you could have dropouts.  Audio file protocols are also robust with similar redundancy checks.  Therefore, audio files are bit perfect on properly designed streamers and DACs on a functioning network due to Ethernet protocols and industry digital music file protocols.
 

The Ethernet assures accurate data packs not timing that you are discussing, unless, as I stated before, the electrical signal over Ethernet carries RF coupled to the streamer or DAC click, where clock function is affected.  Timing from an audiophile perspective is critical when the sequenced  bit perfect data packages are converted to analogue.  So the Ethernet has assured the streamer or DAC has received a bit perfect file in sequence.  The conversion of the sequence is to be at standard timing (44.1, 96 KHz as an example).  The clock assures the standard file timing is accurate at conversion.   If there are timing errors in the digital data packages the resulting analogue voltage steps can jitter, which can introduce noise in the analog waveform. That jitter, in turn, can raise the perceived noise floor, blur subtle details, and reduce soundstage precision.  You experienced better timing is directly proportional to sound quality when you added the external clock.  My experience was different.   The $500 audiophile Ethernet cable was from a very respectable audiophile cable designer/manufacturer.   However, its metal connector housing was coupling RF.   The well designed cheaper cable produced improved SQ because it better insulated RF.  
 

in conclusion:

1. The Ethernet can send corrupted data packages
2. The redundancy in the Ethernet protocols assure data package correction and bit perfect data at the user level if the network connection is sound.  
3. The Ethernet protocols assure correct data sequencing, but this is different from audiophile timing concerns. 
4. Digital music file protocols assure bit perfect music files are timed properly at conversion to analogue.  
5. Therefore, the Ethernet cable does not affect jitter directly.   The way the Ethernet cable can affect jitter is if it is improperly shielded and permits RF coupling affecting clock performance. 
6. Ethernet cables can affect sound quality simply due to physics.  The degree of the effect and the benefit / cost ratio of expensive cables can continue ad nauseam.

Interesting exchange.  Thanks.  Have a phenomenal day and listening experience