audiophile ethernet and USB cables

Posted by: analogmusic on 12 May 2015

I've read up on this on the forum and wanted to confirm and clarify the following

 

1) does the asynchronous USB method use error correction. I understand it does not. So not sure what was the point of ensuring the whole timing gets done properly (audiophilleo in the DAC V1) if we aren't even sure the bits are the right ones to begin with? Did I understand this properly? Otherwise good USB cables should not make a difference, but they do?

 

2) What about TCP/IP? Is there any error correction in the protocol? If not how do computers work if any program can be corrupted during data transmission? While I do understand the better ethernet cables should make a difference if there is no error correction, why does it if indeed there is checking of data integrity

 

Lets try to keep this one simple as I am not an engineer.

 

Thanks in advance to Simon-in-suffolk

Posted on: 12 May 2015 by Foxman50
Originally Posted by SongStream:
Originally Posted by Foxman50:
Originally Posted by SongStream:

Ethernet cables and TCP/IP with regard to audio quality just does not compute to a winner for me.

 

Here is a weird story, and I can't actually believe I am about to post it.  When I was very young, maybe 5 or 6 six years old, I had a record player with a single built in speaker.  I much preferred, for reasons I wouldn't have understood properly at the time, my father's stereo music system.  To address the aesthetic element at least, I made speaker looking....ish things, using two empty cornflake boxes, and ran wires from them, connected to nothing at all ultimately, to the back of my record player.  The next record I played, my jaw dropped in amazement.  They made noise.  The sound actually did come from my lovingly crafted hand made speakers.  That was not what I expected, knowing of course, they were essentially empty cardboard boxes.  I was confused, and I asked my mother to listen.  As I remember, she claimed I had put something behind them to make the sound, and I wasn't actually playing the record.  

 

The mind plays tricks folks, and we...well I, am / are, not as smart as we...possibly I, think.

Yes but how did they sound. You would have got a better sound from Frosties, after all there GGGGreat

Too true.  Personally though, I found Frosties just a little over powering.  In the end, for the reference version, I used Special K for a more lighter more articulate sound.  :-D

Posted on: 12 May 2015 by Nick Lees
Originally Posted by SongStream:

Ethernet cables and TCP/IP with regard to audio quality just does not compute to a winner for me.

 

 

So apart from your charming little story, you've not tried anything, you just "know".

Posted on: 12 May 2015 by Nick Lees
Originally Posted by Simon-in-Suffolk:
Originally Posted by analogmusic:

I've read up on this on the forum and wanted to confirm and clarify the following

 

1) does the asynchronous USB method use error correction. I understand it does not. So not sure what was the point of ensuring the whole timing gets done properly (audiophilleo in the DAC V1) if we aren't even sure the bits are the right ones to begin with? Did I understand this properly? Otherwise good USB cables should not make a difference, but they do?

 

2) What about TCP/IP? Is there any error correction in the protocol? If not how do computers work if any program can be corrupted during data transmission? While I do understand the better ethernet cables should make a difference if there is no error correction, why does it if indeed there is checking of data integrity

 

Lets try to keep this one simple as I am not an engineer.

 

Thanks in advance to Simon-in-suffolk

Hi Analogmusic, I am not an expert in USB design, but you are correct 'Asynchronous USB' has no error correction.  Asynchronous Audio USB uses an isochronous USB transfer method. That is the sender sends the data, and the receiver collects the sent data and puts it in its buffer. If the CRC fails the frame or packet is discarded rather than resent. However for asynchronous audio the key thing is that every 1mS a frame is sent with a specific number of samples. If the receiver starts to receive to much data or starts to run out, it can signal back to the sender by changing the impedance between the data twisted pair of wires at the end of a frame. This is detected by the sender before each frame is sent by the sender and the sender increases or decreases the number of samples every 1mS as appropriate. But there is no data correction - just adjustment of the data rate.

Now why do cables make a difference, well the USB is a transmission line and carries electrical current at radio frequencies. Therefore is liable for emitting and conducting RFI as ell as coupling RFI to the power and ground cables. The balanced serial pair also has its balance deliberately broken as part of the signalling and so is another cause of pulsed RFI. All of this electrical noise needs to careful consideration to reduce its impact.

 

Now TCP/IP is a different beast entirely. It is a set of protocols for communicating data. TCP/IP includes a transport protocol called TCP - and this is used as the transport protocol to transport the packets of data - that include our digitised audio data. TCP's job is to ensure reliable data transfer, as opposed to reliable timing of data (different to asynchronous audio USB which is the other way around)

Therefore the receiver on TCP has a large set of buffers - including specifically one called a 'window'. This window can collect data packets received in different order and timing - and when the window is full it tells the sender all is ok - and the sender and receiver both move onto the next window. This carries on until the data transfer is complete. However if the window never completes, then that window is discarded and is sent again. Both the sender and receiver can dynamically agree the size of this window depending on the reliability of the transfer. A larger window is better, but more susceptible to network transfer errors.

 

Now with TCP there no concept of data timing (other than keeping the receive buffer non empty) . Jitter is meaningless for TCP. Timing is purely managed by the receiver clocking the data out of the received buffer that has been filled by the TCP windows described above. 

 

Again the main consideration of ethernet cables in our audio applciation is to reduce electrical noise and RFI. Data integrity is pretty much assure for our home LANs and if the worst happens is corrected by the TCP protocol, which could be considered over kill for home LANs unless you are using wifi or power line adapters.

 

Audiophile cables waxing lyrical about low jitter, and ability to support non Ethernet frequencies really is  irrelevant and in my opinion hood winking if using the cable for Ethernet.

 

Simon

 

 

 

 

 

 

So if an ethernet cable is particularly good at screening out RFI, say in an environment where this is quite high, then there should be an audible difference.  Isn't this why you add ferrite chokes to them?

Posted on: 12 May 2015 by Foxman50

Is it easy or hard to stop RFI in a CAT cable, I've no idea. My point is if the sound change is just down to FRI then surely all supposed audiophile ethernet cables would sound the same, as they eliminate it or should do.

 

is RFI picked up by the cable or is it in the cable.

 

 

Posted on: 12 May 2015 by SongStream
Originally Posted by Gary Shaw:
Originally Posted by SongStream:

Ethernet cables and TCP/IP with regard to audio quality just does not compute to a winner for me.

 

 

So apart from your charming little story, you've not tried anything, you just "know".

I really don't know.  I've just drawn a line on things I am prepared to worry about.  Based on logic, and knowledge in some areas, and experience in others, that's my view, and nothing more. 

Posted on: 12 May 2015 by Simon-in-Suffolk
Originally Posted by Gary Shaw:

So if an ethernet cable is particularly good at screening out RFI, say in an environment where this is quite high, then there should be an audible difference.  Isn't this why you add ferrite chokes to them?

I am talking about different things. An unshielded ethernet cable relies on the twisted balanced pairs not to radiate or impacted by external RF interference, and by shielding these pairs any imbalance in them and therefore EM leakage or ingress is further mitigated.

 

However magnetic chokes will add inductance to the exterior of the cable at a specific point. Therefore any common mode RF current flowing along the cable (common to balanced pairs or along the shield)  will flow through to the inductor and will at that point be typically impeded and effectively converted to heat. However the voltage/current flowing up to the impedance point can still radiate. 

 

There is a difference between conducted RFI (impeded by the choke) and radiated RFI - which is an electro magnetic field created in the air (dielectric) around the cable.

Posted on: 12 May 2015 by Mike-B
Originally Posted by Foxman50:

Is it easy or hard to stop RFI in a CAT cable, I've no idea. My point is if the sound change is just down to FRI then surely all supposed audiophile ethernet cables would sound the same, as they eliminate it or should do.

 

is RFI picked up by the cable or is it in the cable.

 

 

 

This is where it gets contentious.

I attended a test of audiophile cables in a friends system,  I heard changes between basic Cat5 & the Cat7's,  but I'm not convinced about differences between the Cat7's - AQ Cinnamon, AQ Pearl & Supra.

I bought Supra for my new install,  then (thanks to this forum) got into the various experiments & theories on RFI.   I added ferrites to a lot of cables related to ethernet, the ethernet's themselves, SMPS & each of the mains supplies & finally a new UPS with its isolation transformer.  I then independently researched & correctly terminated the grounding of my LAN screen in my whole system. 

Did it change the SQ? - nothing that I could hear with each of the incremental changes,  however I recently hooked up a temporary Cat5 between NDX & switch, this removed the screen ground & one ferrite,  & the SQ change was audible, but subtle.

 

Whats going on,  I really don't know.  I'm happy it does what it does, however I am a nerdish technofreak & would really like to dig into this,  but I do not have anything like the equipment or expertise needed to do this - & incidentally I have yet to see anything on www that gets close to prove anything one way or another . 

Do I believe different ethernet sounds different ?,  I believe so but I really don't know why. TCP checks for errors & requests re-transmissions if/when errors exist,  that says all correct spec ethernet should all sound the same, & maybe its unresolved errors & maybe other issues such as crosstalk & RFI that degrade SQ & not the super cables that make SQ even better.  = who knows.

 

 

Posted on: 12 May 2015 by Sneaky SNAIC

The key in my book as far as Ethernet and TCP/IP goes, is buffering.  The idea is to send it before you need and buffer it up (I'm pretty sure the Naim streamers have buffering).  If you are buffering enough data you simply don't need to worry about anything with TCP.

 

TCP/IP includes both TCP and UDP, but TCP guarantees delivery and the correct order of data.  UDP does not guarantee either, but is faster (used for real time stuff).

 

Doesn't matter what cable you use...is there exists a decent buffer you won't have any issues.  Networks are lightning fast nowadays and its not like you are getting music drip, drip through the Ethernet "just in time" to play it...in fact with a decent buffer you can send the entire song nearly instantly and buffer it for playback on the local device.

 

Once the music is there, assembled on the target device it didn't matter what type of cable you sent it through because the 0's and 1's will be guaranteed by the protocol.  The only issue I can see with this type of setup is if you have a very congested network with lots of collisions.

Posted on: 12 May 2015 by analogmusic

So which method do NDX and Linn streamers such as KDS/1 use?

 

TCP or UDP?

Posted on: 12 May 2015 by Simon-in-Suffolk

UPnP, web radio and streaming services use TCP for media transfer.

UDP is used for the multicast protocols which are used for some control and discovery functions on the LAN with UPnP and AppleTalk/Bonjour.

 

To the point of Ethernet cables affecting sound 'quality'. As I have said before it is essentially nothing to do with digital data payload unless the cable is broken, but about, whether all or in part, the cross talik, interference and transmission line effects caused by the transmitting and receiving the low level analogue voltages across the balanced pairs. Remember essentially the Ethernet cable carries Manchester encoded three level analogue voltages.. The analogue data doesn't look like digital network data until it is further processed. The analogue voltages are converted into a digital payload. At the physical level Ethernet uses a sort of DAC and ADC across the signal pairs. The signals on the Ethernet lead are ultimately analogue.

Simon

Posted on: 13 May 2015 by Claus-Thoegersen

I visited Chord a few weeks ago. They compared normal Network cable with there own, and unfortunately there was a difference. If I used a streamer I would have a listen to the cheaper Chord alternatives, with a server I do not think it is that important, but I will try out one of  the Chord Network cables at some time.   

Posted on: 13 May 2015 by Bert Schurink

Simon I am very happy that you are on this forum, you always have a good insight in the deep technical aspects and you can explain it in a way that everybody understands and can appreciate the why.

Thank you for your contributions.

Posted on: 13 May 2015 by Foxman50
Originally Posted by Bert Schurink:

Simon I am very happy that you are on this forum, you always have a good insight in the deep technical aspects and you can explain it in a way that everybody understands and can appreciate the why.

Thank you for your contributions.

@Bert - Are you sure, it confuses the hell out of me but i really appreciate Simon's posts as it shows how little i know. I try to pick up what i can from them though. It also shows how much is going on in these cables.

 

@Simon - reading your post above, if i understand correctly, are you saying that these analogue voltages within the cable could potentially affect sound quality, through the different make up of cables. When you read about them they seem to make a big issue of containing silver. I think you need to open a forum live meeting and give us all a run through this technology

Posted on: 13 May 2015 by james n

One thing I have wondered about regarding Ethernet cables is the streamer module itself and its affect on the DAC section of the player. The NDX white paper mentioned the Naim preference for WAV files to decrease the computational load so not raising the power supply noise floor.

 

If the Streamer card is needing to do a lot of re-requests etc does this also result in increased loading and subsequent changes in both the radiated and conducted noise the streamer card produces - ultimately resulting in changes in the analogue domain, either through noise affecting the DAC conversion clock or intermods further downstream of the DAC.

 

IIRC correctly Simon, didn’t you find SQ variations in Naim network players with the TCPIP stack of various servers – was this down to the streamer card ?

 

James

Posted on: 13 May 2015 by Foxman50
Originally Posted by Wat:

The method of delivery of data packets into a buffer makes no discernable difference to me as long as what is delivered is correct. 

 

I'm unimpressed with Chord Company's demos. The only way to see if these cables work for you is to try in your system, but how many boutique cables do you need to try? Are they better than AudioQuest, Supra or Maplin? We always get the argument: but you haven't heard them ... But have those putting this argument heard good quality Ethernet cable used in industry? I just don't buy it. Medical and Military grade cables are available and far cheaper. 

 

So are Chord et al ... comparing with a high grade cable. Yes I have been to a Chord demo & I heard absolutely nothing beneficial. Of course, we all hear differently, so my experience may not be the same as somebody else. 

 

Up to you ... Buy what you feel is best .... My recommendation remains Maplin  

Wat

 

You make a very good point, but how do those like myself know what a good cable is. I think this is why we rely on audiophile cables.

 

Graeme

Posted on: 13 May 2015 by Solid Air

Specifically on Ethernet (I don't know enough about Asynch USB to comment):

 

The streamers do buffer. If you unplug the cable while it's playing it doesn't stop immediately, so there's a buffer which contains the fully-corrected data. In effect, as S-i-S says, we should assume that the data is a perfect version of what was sent. So any change in SQ is due to something else, likely to be RFI. So even if we assume that RFI is a factor - which I'm not sure is a proven hypothesis - then the question is, do audiophile cables cause less RFI to be transmitted to the streamer than other cables?

 

Cable demos at the vendor's location are obviously flawed. To provide a true test you would need to do it on your own system and with a variety of cables, ideally blind. The cables would have to include cheapo Maplin, but also good non-audiophile quality and various levels of audiophile brand cables.

 

I've looked for examples outside of audiophile use. Even the most expensive regular cables are far from expensive - fully shielded Cat5e and Cat6, etc. Applications where RFI might be an issue such as in hospitals or the army (!) use standard industrial ethernet cables that cost a few pounds per metre.

 

Posted on: 13 May 2015 by Simon-in-Suffolk

Solid Air, I don't know about MOD equipment as I have no experience, but medical Ethernet equipment is covered by IEC 60601-1 (3rd edition) - and addresses primarily electrical safety and isolation so as to protect a connected patient from leakage currents - which is often achieved in part through highly specified galvanic isolation of low frequency AC like mains voltages and DC voltages.

I suspect the low level EMC effects we are sensitive to in our hifi is not really of interest in the medical world - as outside the above I very much doubt its a safety issue

Simon

 

Posted on: 13 May 2015 by Simon-in-Suffolk
Originally Posted by Foxman50:

@Simon - reading your post above, if i understand correctly, are you saying that these analogue voltages within the cable could potentially affect sound quality, through the different make up of cables.

Yes - just like mains leads and digitial SPDIF leads can affect the sound (not necessarily quality) of the connected equipment.

 

James - yes I (and others) have heard sonic differences between different UPnP media servers in different computing environments. The digital payload is exactly the same, but the TCP parameters and therefore the dynamics of the data flow vary - and this seemed to create an audible signature - not unlike FLAC vs WAV in the streamer.

Since I have moved to the NDX feeding the Hugo - I no longer hear any substantive difference from the UPnP media server source - or even WAV vs FLAC vs ALAC

Simon

Posted on: 13 May 2015 by james n

Cheers Simon - that's interesting to know. 

 

James

 

Posted on: 13 May 2015 by Nick Lees

At the end of the day all you can do is use your ears. Theorising about it might float your boat but listening is easy and conclusive.

 

If, as I did, you try a few and here a difference that's worth paying for then fine. If you listen and you hear nothing, then fine also.

 

Talking about it on the internet won't answer the question.

Posted on: 13 May 2015 by Foxman50

Wat, have you found this USB cable improves sound quality. Will this work with the new TT, i take it it doesn't need the power connections

 

Graeme

Posted on: 13 May 2015 by Foxman50
Originally Posted by Simon-in-Suffolk:
Originally Posted by Foxman50:

@Simon - reading your post above, if i understand correctly, are you saying that these analogue voltages within the cable could potentially affect sound quality, through the different make up of cables.

Yes - just like mains leads and digitial SPDIF leads can affect the sound (not necessarily quality) of the connected equipment.

 

James - yes I (and others) have heard sonic differences between different UPnP media servers in different computing environments. The digital payload is exactly the same, but the TCP parameters and therefore the dynamics of the data flow vary - and this seemed to create an audible signature - not unlike FLAC vs WAV in the streamer.

Since I have moved to the NDX feeding the Hugo - I no longer hear any substantive difference from the UPnP media server source - or even WAV vs FLAC vs ALAC

Simon

Cheers Simon

Posted on: 13 May 2015 by james n

I quite agree Wat - an Ethernet cable is an Ethernet cable (provided it is within spec). I suppose the question really to ask is if i plug one of these 'audiophile' cables into my system and hear a difference then what is that cable doing that makes the difference. I'm surprised one of the more technically advanced publications (such as Critic) have't done some testing to correlate subjective impressions against measured parameters. 

 

Nailing my colours to the mast, i'm USB these days. I couldn't tell the difference between a 1m wireworld starlight cable and a 5m generic cable i borrowed from my Concept 2 Rower but a Chord Silver plus did really make a noticeable difference so it stayed. Why ? - i'd be keen to know. 

 

James

Posted on: 13 May 2015 by Foxman50

James, when you say it made a difference, what was the difference.

 

Graeme

Posted on: 13 May 2015 by SongStream
Originally Posted by james n:

I quite agree Wat - an Ethernet cable is an Ethernet cable (provided it is within spec). I suppose the question really to ask is if i plug one of these 'audiophile' cables into my system and hear a difference then what is that cable doing that makes the difference. I'm surprised one of the more technically advanced publications (such as Critic) have't done some testing to correlate subjective impressions against measured parameters. 

 

Nailing my colours to the mast, i'm USB these days. I couldn't tell the difference between a 1m wireworld starlight cable and a 5m generic cable i borrowed from my Concept 2 Rower but a Chord Silver plus did really make a noticeable difference so it stayed. Why ? - i'd be keen to know. 

 

James

I had a similar experience for what it's worth with USB.  I'd used something I had lying about initially, but then used a higher quality (as in better made, not audiophile) Belkin cable, but heard no difference.  I then tried the Furutech Formula 2, similar price point to the Chord actually, and I did hear a significant benefit.  I have theorised about it, and can see possible explanations, but nothing that really convinces me it wasn't all in my head.  However, I hate the whole A/B test stuff, and faffing about with my system, so based on the fact that it was sounding good to me, I haven't unplugged it since I first installed it.