Audiophile Ethernet cables - The World Has Gone MAD!
- Thread starter Krisman
- Start date
Thanks for that gem oldmate, it made me smile 
Why are ethernet cables funny but coax/usb cables not? If you buy the one you could buy the other as well.
Clean Ethernet implementation is one of the most important thing for a good setup imo. Don't know how much the cable takes place in this tho.
Clean Ethernet implementation is one of the most important thing for a good setup imo. Don't know how much the cable takes place in this tho.
Last edited:
Audiophile USB cables are funny as well. Coax depends on whether they carry analog or digital, and when digital (under discussion here I assume) it depends on the protocol (Ethernet over coax, or S/PDIF etc.).
Assuming the connection isn't totally bad due to corrosion etc, the key consideration is whether the cable, in some form or other, needs to carry the master clock signal as well aside from the data. With S/PDIF the master clock signal itself is pushed over the digital interface (at least in the the original implementation, some DAC manufacturers have attempted workarounds), hence the DAC needs to synch it's own clock to that of the device sending the S/PDIF bitstream, which can cause synchronisation problems, lead to jitter in the time domain and hence noise in the frequency domain. This is particularly "bad" for optical S/SPDIF (TOSLINK) connections, as the optical cable isn't mono-mode, the coupling numerical aperture is quite high, and over fibre lengths > 1m thus enough smearing of the different optical paths through the cable can cause timing issues on flank detection at the DAC-end. This also affects S/PDIF over coax; albeit to a lesser extent and more because of reflections at poorly matched impedance at the cable ends; hence longer coax S/PDIF cables are supported than optical S/PDIF fibre-cables.
With Ethernet however there is complete a-synchronicity of data packets, and the DAC carries the master clock; i.e. it asks for more data packets to be sent as it's data buffer empties. Any timing problems therefore are irrelevant to ethernet connections, lost data packets due to noise etc. simply get re-sent if not acknowledged as correctly received. This is a situation analogous to that found internally in CD-players (incl. the resending of lost packets if we are looking at modern PC-style CD transports, not classic CD transports.) In CD players, exact timing of the S/PDIF bitstream from the digital filter to the DAC is directed by the master clock, not by whether the CD spins around at the exact correct speed; the CD speeds up and slows down as the FIFO data buffer feeding the digital filter fluctuates at around 50% capacity.
Thus the classic concept of audio cable quality used with reference to ethernet cables is a bit non-sensical. With an Ethernet protocol, data packets get sent much faster than required by the DAC, get buffered by the DAC and used at the correct "rate" by the DAC, as governed by the master clock of the DAC; some more data packets get sent over the ethernet connection as the buffer empties and the DAC asks for it, lost/corrupted data packets get re-sent, etc. etc. I am less familiar with the data protocols over USB, but I assume a similar argument applies. Issues should only become noticeable if the ethernet connection is so bad that packet loss start to exceed the rate at which packets are required by the DAC (corroded connectors, physical intermittent break in the cable, heavy RF interference, ethernet cables run alongside noisy power cables for significant lengths, CAT6 cables bent at too sharp an angle near other sources of electrical noise, etc.)
Assuming the connection isn't totally bad due to corrosion etc, the key consideration is whether the cable, in some form or other, needs to carry the master clock signal as well aside from the data. With S/PDIF the master clock signal itself is pushed over the digital interface (at least in the the original implementation, some DAC manufacturers have attempted workarounds), hence the DAC needs to synch it's own clock to that of the device sending the S/PDIF bitstream, which can cause synchronisation problems, lead to jitter in the time domain and hence noise in the frequency domain. This is particularly "bad" for optical S/SPDIF (TOSLINK) connections, as the optical cable isn't mono-mode, the coupling numerical aperture is quite high, and over fibre lengths > 1m thus enough smearing of the different optical paths through the cable can cause timing issues on flank detection at the DAC-end. This also affects S/PDIF over coax; albeit to a lesser extent and more because of reflections at poorly matched impedance at the cable ends; hence longer coax S/PDIF cables are supported than optical S/PDIF fibre-cables.
With Ethernet however there is complete a-synchronicity of data packets, and the DAC carries the master clock; i.e. it asks for more data packets to be sent as it's data buffer empties. Any timing problems therefore are irrelevant to ethernet connections, lost data packets due to noise etc. simply get re-sent if not acknowledged as correctly received. This is a situation analogous to that found internally in CD-players (incl. the resending of lost packets if we are looking at modern PC-style CD transports, not classic CD transports.) In CD players, exact timing of the S/PDIF bitstream from the digital filter to the DAC is directed by the master clock, not by whether the CD spins around at the exact correct speed; the CD speeds up and slows down as the FIFO data buffer feeding the digital filter fluctuates at around 50% capacity.
Thus the classic concept of audio cable quality used with reference to ethernet cables is a bit non-sensical. With an Ethernet protocol, data packets get sent much faster than required by the DAC, get buffered by the DAC and used at the correct "rate" by the DAC, as governed by the master clock of the DAC; some more data packets get sent over the ethernet connection as the buffer empties and the DAC asks for it, lost/corrupted data packets get re-sent, etc. etc. I am less familiar with the data protocols over USB, but I assume a similar argument applies. Issues should only become noticeable if the ethernet connection is so bad that packet loss start to exceed the rate at which packets are required by the DAC (corroded connectors, physical intermittent break in the cable, heavy RF interference, ethernet cables run alongside noisy power cables for significant lengths, CAT6 cables bent at too sharp an angle near other sources of electrical noise, etc.)
Users who are viewing this thread
