advertisement


Ethernet cables and Sound Quality

T

tinpot

General
There are companies that sell very expensive (copper) Ethernet cables, and people that buy them.

When playing an audio file from a file server (a NAS is a file server), the audio is encoded (be it WAV, M4A, FLAC etc), the file is then packetised into TCP packets, the TCP packets are then encapsulated into Ethernet frames, the Ethernet frames are then sent as a bitstream (with preamble, Start of Frame and CRC) by the Ethernet NIC; presuming there is no switch or router in between, this sequence is then reversed by the "playing" device.

Given above sequence of encoding, packetisation and encapsulation before the bistream which goes over the cable, I am interested in how people think that different Ethernet cables can affect the sound quality.

I am also interested in why none of the high end audio manufactures sell any devices with SFP or SFP+ to allow for fibre connectivity.
 
As a one-time computer technician, I am totally sure that data gets through the cable 100% bit perfect. If it didn't a lot of software wouldn't work !
HOWEVER I believe that the cable may have an effect on the device at the receiving end that might possibly affect a digital-analogue conversion.
I have to say though that I am quite happy to use decent quality off-the-shelf Cat6 throughout my home network and I certainly wouldn't pay silly money for any digital cable.
 
Cannot see how something that requires bit perfect data will be bothered by whatever cable it uses.

In one job I had we used to run 1000 feet plus runs of RS232 cables when the tech boys said 100 feet and the signal would drop out, but we never lost a bit of data so I think any old cable would work happily.

I put a system in using Homeplugs through the house mains wiring and it sounds perfect, so no cat cable involved in that, apart from the 13amp Homeplug at the router to the other 13amp Homeplug by the streamer.
 
As I mentioned in the powerline thread, all this complicated tech is flakey and relies on quality control at the cheapest price ie a conflict. Digital problems are hard to troubleshoot, because out of spec faults do not produce analogue like symptoms. All digital systems have corrections and redundancy by design, so things that are marginal can have intermittent faults. We used to see this on huge coax networks back in the 90s, when people stuck the wrong cable in, builders altered things etc. It soldiers on, working badly, until a final problem kills it. Logic tells you that you get one fault at a time, but in IT you see lots of situations where 2 faults just about works, and 3 falls over. The only way to get to the bottom of this is to have far more kit than you need to connect - spare cables, switches, routers, dongles etc. Then you swap out until the worst problem is found. Any cable can be marginally made or get damaged, so buy 2 cheapish cables from different sources, not 1 foo-cable, and not the cheapest parts in the world.
 
Funny you should post about this as Loud & Clear Hi-Fi are having an ethernet cable bake-off today at their Glasgow store between 12 and 4pm. I'm working so I won't be going, I probably wouldn't have went anyway, but perhaps some punters will get a chance to find out for themselves whether there is any difference to be heard and whether that difference - if there's a difference(!) - is worth the asking price.

Click here for more info on the bake-off
 
demotivated said:
As I mentioned in the powerline thread, all this complicated tech is flakey and relies on quality control at the cheapest price ie a conflict. Digital problems are hard to troubleshoot, because out of spec faults do not produce analogue like symptoms. All digital systems have corrections and redundancy by design, so things that are marginal can have intermittent faults. We used to see this on huge coax networks back in the 90s, when people stuck the wrong cable in, builders altered things etc. It soldiers on, working badly, until a final problem kills it. Logic tells you that you get one fault at a time, but in IT you see lots of situations where 2 faults just about works, and 3 falls over. The only way to get to the bottom of this is to have far more kit than you need to connect - spare cables, switches, routers, dongles etc. Then you swap out until the worst problem is found. Any cable can be marginally made or get damaged, so buy 2 cheapish cables from different sources, not 1 foo-cable, and not the cheapest parts in the world.
Click to expand...

So are you suggesting there would be transmission errors that would be causing audible changes to the sound?
 
windhoek said:
Funny you should post about this as Loud & Clear Hi-Fi are having an ethernet cable bake-off today at their Glasgow store between 12 and 4pm. I'm working so I won't be going, I probably wouldn't have went anyway, but perhaps some punters will get a chance to find out for themselves whether there is any difference to be heard and whether that difference - if there's a difference(!) - is worth the asking price.
Click to expand...

It is labeled as "comparative demonstrations", and I guess we should read that as "sighted attempts at convince people there is a difference"...
 
zippy said:
HOWEVER I believe that the cable may have an effect on the device at the receiving end that might possibly affect a digital-analogue conversion.
I have to say though that I am quite happy to use decent quality off-the-shelf Cat6 throughout my home network and I certainly wouldn't pay silly money for any digital cable.
Click to expand...

So by what mechanism do you think the sound might be affected? Noise conducted through the ground/earth/shielding? That would be one reason to use only UTP (unshielded twisted pair) instead of STP (shielded twisted pair). The actual signal connections in an ethernet interface are galvanically isolated (tiny transformers usually referred to as "magnetics"), but the shielding isn't.
 
Julf said:
So are you suggesting there would be transmission errors that would be causing audible changes to the sound?
Click to expand...

I haven't looked into it. Currently I don't transfer much music over ethernet, just listening to utube on a PC thru hifi, which sounds very pleasant. My point was to have a spare cable etc, if you think there is an issue.

If I have to guess, I can't see how cost [above what it takes to pay someone to do a quality job in a low pressure factory] would improve a cable.
 
I believe for every drop of rain a flower grows.
I believe and I trust my ears (even when I have a cold). But I don’t trust yours
 
demotivated said:
If I have to guess, I can't see how cost [above what it takes to pay someone to do a quality job in a low pressure factory] would improve a cable.
Click to expand...

Indeed. And my point is that any issues would also affect any other data transfers, not just music.
 
Don't use a shielded cable when only one end has a shielded socket. In a house there is little reason to use STP cable as the Ethernet transformers block mains interference very well
 
I work within IT and networking, including some work with PTP; my "informed" view on "expensive network cables" is that they are snake oil possibly producing something akin to a placebo effect in purchasers, they think it is better, so they hear it is better.

As to the suggestion that noise can make its way into a playback device through the Ethernet port,from my point of view that would indicate poor to appallingly bad design.

My question about the use of SFP/SFP+ (1G/10G Ethernet) is however very serious, although optics for Ethernet are conceptually similar to optics for TOSLINK, the implementation is very different.

Reading the information on the "bake off", they mention changing nothing apart from the cable, swapping cables is not the way to do a listening test, switching inputs is much faster, presuming that the preamp has been checked to be the same on all inputs...
 
tinpot said:
When playing an audio file from a file server (a NAS is a file server), the audio is encoded (be it WAV, M4A, FLAC etc), the file is then packetised into TCP packets, the TCP packets are then encapsulated into Ethernet frames, the Ethernet frames are then sent as a bitstream (with preamble, Start of Frame and CRC) by the Ethernet NIC; presuming there is no switch or router in between, this sequence is then reversed by the "playing" device.
Click to expand...

It depends on your definition of a "file server". Media servers (most NAS devices are also media servers) sometimes use UDP rather than TCP to improve performance. With UDP error correction is left to the application, which could mean that there is no error correction.

tinpot said:
I am also interested in why none of the high end audio manufactures sell any devices with SFP or SFP+ to allow for fibre connectivity.
Click to expand...

You would have to ask the manufacturers, but I would guess this is down to increased cost, the potential for compatibility issues, a lack of demand and the lack of any real benefit over copper cabling in a domestic setting.

Julf said:
Indeed. And my point is that any issues would also affect any other data transfers, not just music.
Click to expand...

Yes, but those issues might not be as noticeable with other data transfers. For example, a straight file copy from one place to another might just take a little longer than it otherwise would, as lost packets are detected and resent. With music streaming you might experience a break in playback.
 
Strictly Stereo said:
It depends on your definition of a "file server". Media servers (most NAS devices are also media servers) sometimes use UDP rather than TCP to improve performance. With UDP error correction is left to the application, which could mean that there is no error correction.
Click to expand...

Ethernet frame structure has CRC (error correction) within the FCS, independent of whether it is UDP or TCP on top.

"Frame check sequence[edit]
The frame check sequence (FCS) is a four-octet cyclic redundancy check (CRC) that allows detection of corrupted data within the entire frame as received on the receiver side. The FCS value is computed as a function of the protected MAC frame fields: source and destination address, length/type field, MAC client data and padding (that is, all fields except the FCS).[3]:section 3.2.9

Running the CRC algorithm over the received frame data including the CRC code will always result in a zero value for error-free received data, because the CRC is a remainder of the data divided by the polynomial. However, this technique can result in "false negatives", in which data with trailing zeroes will also result in the same zero remainder. To avoid this scenario, the FCS is complemented (reversed for each bit) by the sender before it is attached to the end of the payload data.[3]:section 3.2.9 This way, the algorithm result will always be a magic number or CRC32 residue of 0xC704DD7B when data has been received correctly. This allows for receiving a frame and validating the FCS without knowing where the FCS field actually starts."

This is all layer 2 stuff and unavoidable on any ethernet connection.
 
You must log in or register to reply here.


advertisement


Back
Top