Ethernet Cables - which are the most important?

[Ralf11]

Despite what people will tell you, as long as they provide a reliable connection, Ethernet cables make no difference whatsoever. Cat 5e is good for gigabit speeds over at least 100 feet. While there are cheap cables that don't quite meet the specs, Belkin is perfectly fine. Stick with them and spend your money where it matters, such as on music.

 

xlnt advice, directly stated

 

can I just add for the final word, I'd substitute "better mastered or recorded music, speakers, and/or room and room treatments"

[Jud]

Though starting out kind of dubious about Ethernet cables making any difference to SQ, I did hear a Baaske Ethernet iso transformer make a clear audible difference to the noise level in my system with a "noise sniffer" type box in the circuit. My suspicion would be that it would be noise (leakage current?) rather than data transmission and reception integrity that might account for any real audible differences.

 

Though I've never listened to a system with expensive Ethernet cables, I do very much wonder whether they would have better noise behavior than a couple of Blue Jeans cables and a Baaske isolator (about $60 used).

 

 

Sent from my iPhone using Computer Audiophile

[scan80269]

I have no idea. I'll need to do the "unplug Ethernet cable while playing audio" to the microRendu, Aries Femto and Aries Mini and report the results. Aries models with 4.0 firmware or later has implemented RAM playback, so I expect the music to keep playing quite a bit longer vs. the microRendu after the Ethernet cable is unplugged.

 

 

These days I prefer to use Blue Jeans Cable Ethernet cables, as each cable ordered is shipped with a 1-page test report showing spec compliance as well as graphs showing margin for NEXT and RL. It is BJC who claims to have measured various CAT6 cables and found spec violations:

 

Is Your Cat 6 Cable a Dog? -- Blue Jeans Cable

 

I frankly don't believe those spec violations are as serious as BJC has claimed in practice for general networking use (again since Ethernet is so robust), but I'm willing to believe they can be more significant for digital audio streaming over Ethernet, in terms of SQ delivered by the streamer.

 

Here are some quick results on how long it takes a streamer to stop playing music after the Ethernet cable is unplugged. In each case, I selected a track to play, waited 15 seconds, then unplugged the Ethernet cable and timed how long the streamer continued music playback. Content was 16/44.1K Redbook. Ethernet connection between music server and streamer was gigabit.

 

* Sonore microRendu (in MPD/DLNA mode): 39 seconds or less

 

* Auralic Aries Femto: current track (7:09 in length) played to completion

 

* Auralic Aries Mini: inconsistent behavior - playback either stopped after 5-10 seconds or track played to completion (I tried tracks of 1:58, 3:34 & 7:09 lengths)

 

Per Auralic firmware release notes, Aries Mini with 4.0 & higher firmware uses 64MB as memory cache, which is good for about 6.5 minutes of Redbook music. Longer or higher resolution tracks cannot be completely preloaded into memory, and Aries Mini appears sensitive to a networking disruption leading to playback stoppage, even before the existing preloaded portion finishes playing from memory.

 

Aries Femto (& Aries LE) uses a 512MB memory cache, enough to buffer about 50 minutes of Redbook music.

 

For microRendu, the observed sustained playback duration calculates to a buffer size of just under 7MB.

[kumakuma]

Here are some quick results on how long it takes a streamer to stop playing music after the Ethernet cable is unplugged. In each case, I selected a track to play, waited 15 seconds, then unplugged the Ethernet cable and timed how long the streamer continued music playback. Content was 16/44.1K Redbook. Ethernet connection between music server and streamer was gigabit.

 

* Sonore microRendu (in MPD/DLNA mode): 39 seconds or less

 

* Auralic Aries Femto: current track (7:09 in length) played to completion

 

* Auralic Aries Mini: inconsistent behavior - playback either stopped after 5-10 seconds or track played to completion (I tried tracks of 1:58, 3:34 & 7:09 lengths)

 

Per Auralic firmware release notes, Aries Mini with 4.0 & higher firmware uses 64MB as memory cache, which is good for about 6.5 minutes of Redbook music. Longer or higher resolution tracks cannot be completely preloaded into memory, and Aries Mini appears sensitive to a networking disruption leading to playback stoppage, even before the existing preloaded portion finishes playing from memory.

 

Aries Femto (& Aries LE) uses a 512MB memory cache, enough to buffer about 50 minutes of Redbook music.

 

For microRendu, the observed sustained playback duration calculates to a buffer size of just under 7MB.

 

Did you notice any change in sound quality after the cable was unplugged?

[scan80269]

Did you notice any change in sound quality after the cable was unplugged?

 

Sorry I didn't listen for any SQ changes. Also, I used the upstairs bedroom setup based on a pair of KEF X300A speakers. This specific setup is arguably not sufficiently resolving to reveal SQ changes. I'll need to schedule another listening session at my friend's venue to determine if unplugging the Ethernet cable from a streamer can result in audible sound quality change.

[plissken]

Here are some quick results on how long it takes a streamer to stop playing music after the Ethernet cable is unplugged. In each case, I selected a track to play, waited 15 seconds, then unplugged the Ethernet cable and timed how long the streamer continued music playback. Content was 16/44.1K Redbook. Ethernet connection between music server and streamer was gigabit.

 

* Sonore microRendu (in MPD/DLNA mode): 39 seconds or less

 

* Auralic Aries Femto: current track (7:09 in length) played to completion

 

* Auralic Aries Mini: inconsistent behavior - playback either stopped after 5-10 seconds or track played to completion (I tried tracks of 1:58, 3:34 & 7:09 lengths)

 

Per Auralic firmware release notes, Aries Mini with 4.0 & higher firmware uses 64MB as memory cache, which is good for about 6.5 minutes of Redbook music. Longer or higher resolution tracks cannot be completely preloaded into memory, and Aries Mini appears sensitive to a networking disruption leading to playback stoppage, even before the existing preloaded portion finishes playing from memory.

 

Aries Femto (& Aries LE) uses a 512MB memory cache, enough to buffer about 50 minutes of Redbook music.

 

For microRendu, the observed sustained playback duration calculates to a buffer size of just under 7MB.

 

Then you have a test bed. If the issue is some form of induced noise, or ground coupling (when there shouldn't be) then it will go away when you pull the plug and reappear when you plug it back in.

 

What I wouldn't expect to happen is that it continues to sound bad after the cable is pulled. It's just data at this point and we know that what you are hearing that instant was read into buffer 39 seconds before for the microRendu and 7:09 for the Aries Femto.

 

If these streamers are sounding bad then honestly it's a streamer I wouldn't want because somewhere the implementation is fucked up.

[mansr]

Though starting out kind of dubious about Ethernet cables making any difference to SQ, I did hear a Baaske Ethernet iso transformer make a clear audible difference to the noise level in my system with a "noise sniffer" type box in the circuit. My suspicion would be that it would be noise (leakage current?) rather than data transmission and reception integrity that might account for any real audible differences.

 

Are you aware that Ethernet always has a transformer at either end? These days they are usually integrated in the RJ45 jack. Nothing below a few MHz gets through these.

[Jud]

Are you aware that Ethernet always has a transformer at either end? These days they are usually integrated in the RJ45 jack. Nothing below a few MHz gets through these.

 

"Eppur si muove."

Yes, I am well aware of that, which is why, as I mentioned, I was dubious about the possibility that anything involving Ethernet cables would make any difference. However: When I said I had a "noise sniffer" type box in the circuit that made system noise audible, I mean *very* audible, nothing on the fringes of perception. And the Baaske transformer beyond any doubt considerably reduced the volume of this noise.

 

Not the box I used, but for an example of the type of thing I mean when I say the initial noise and the reduction were audible beyond doubt, the following will serve nicely:

 

 

 

I think I recall seeing something about the Baaske isolators and leakage current, which is why I speculated that might be it in my quote above. But I really don't know what sort of noise current might survive the transformers in regular Ethernet connections, yet would be minimized by the Baaske isolator.

[r_w]

Agree 100%

 

... but I tried a Baaske isolator on my LAN after an FMC, I think it was slightly better without... meaning that converting to fibre is probably optimal... as for big dollar LAN cable, that just sounds daft - fibre IMHO appears to be the obvious route with the shortest possible cable from FMC (powered by battery, or LPS) to server.

 

 

Though starting out kind of dubious about Ethernet cables making any difference to SQ, I did hear a Baaske Ethernet iso transformer make a clear audible difference to the noise level in my system with a "noise sniffer" type box in the circuit. My suspicion would be that it would be noise (leakage current?) rather than data transmission and reception integrity that might account for any real audible differences.

 

Though I've never listened to a system with expensive Ethernet cables, I do very much wonder whether they would have better noise behavior than a couple of Blue Jeans cables and a Baaske isolator (about $60 used).

 

 

Sent from my iPhone using Computer Audiophile

[witchdoctor]

Now if you would only read the terms.

 

I accept paypal, NP:)

[Jud]

Then you have a test bed. If the issue is some form of induced noise, or ground coupling (when there shouldn't be) then it will go away when you pull the plug and reappear when you plug it back in.

 

What I wouldn't expect to happen is that it continues to sound bad after the cable is pulled. It's just data at this point and we know that what you are hearing that instant was read into buffer 39 seconds before for the microRendu and 7:09 for the Aries Femto.

 

If these streamers are sounding bad then honestly it's a streamer I wouldn't want because somewhere the implementation is fucked up.

 

 

I suppose it might continue to sound bad after the cable was pulled if the problem wasn't with the streamer and Ethernet implementation, but was for example something to do with noise kicked back into the system by a router/bridge "wall wart" power supply.

[plissken]

I suppose it might continue to sound bad after the cable was pulled if the problem wasn't with the streamer and Ethernet implementation, but was for example something to do with noise kicked back into the system by a router/bridge "wall wart" power supply.

 

Once the cable has been pulled it should break the connection and the noise should disappear. Even at that point I wouldn't attempt to fix it with a $350 three foot Ethernet cable.

 

Texas Instruments has a research paper on balanced signaling where they point out that the unbalanced power supply could introduce problems. It's not a guarantee but just points out the potential and it should always be considered in scope when troubleshooting.

[plissken]

I accept paypal, NP:)

 

That's funny. So do I.

[Cebolla]

Aries Mini appears sensitive to a networking disruption leading to playback stoppage, even before the existing preloaded portion finishes playing from memory.

All that can be concluded is that buffering of the audio file being networked streamed under UPnP/DLNA occours only if the device doesn't stop playing after its network cable is unplugged. How can you be certain that any reasonable amount of a 'preloaded portion' even exists on the Aries Mini's 64Mb cache - all you've only got is notice a 64MB cache being available for UPnP playback on a firmware release note.

[plissken]

@plissken, I understand your challenge but what exactly is the video demonstrating?

 

It's showing the system with 2 network adapters in a LAG. This allows the swapping of a $12 and $350 cable w/o interruption in playback.

 

That is as a listener, if you think you can tell the difference, this should allow you to swap and follow the bouncing ball. Alternately this will allow me do administer a single blind test.

[scan80269]

All that can be concluded is that buffering of the audio file being networked streamed under UPnP/DLNA occours only if the device doesn't stop playing after its network cable is unplugged. How can you be certain that any reasonable amount of a 'preloaded portion' even exists on the Aries Mini's 64Mb cache - all you've only got is notice a 64MB cache being available for UPnP playback on a firmware release note.

Well, of course I cannot claim to understand how the Aries Mini track buffering works. However, I have noticed that the Mini exhibits different behavior depending on the length of the track being played. For short tracks, there is only one burst of high networking traffic from the music server at the point the track is selected for playback, or for continuous playback, I see a networking burst to preload the next track about 15 seconds before the beginning of that track. For long tracks, a networking burst occurs every 48-49 seconds, each lasting very roughly 2 seconds. From what I can tell, each burst transfers way more than 5-10 seconds worth of the current track into the Mini. This is what led me to speculate that some other mechanism is at work leading to playback stoppage well before the existing preloaded portion has played through.

 

I probably should have avoided using the term "inconsistent behavior" to describe the Aries Mini. A better term would be "bimodal behavior".

 

BTW, I have been in communication with Auralic on an unexpected playback stoppage issue with the Mini at 100Mbps networking speed (nothing to do with unplugging Ethernet cable). Auralic has traced the issue to a compiler bug, and is working on a fix in firmware to be available for beta testing in a month or so, and I have volunteered my Mini to help test the beta release.

[cordobaman]

I'm using a Rosewill 5-port gigabit switch box to feed the various components in my system (DAC, BD player). It has a cheapo switching wall-wart. Would there be any noise reduction advantage to a upgrade to an lps wall wart such as this?

 

https://www.ebay.com/itm/311714308385

 

 

Sent from my iPad using Computer Audiophile

[Albrecht]

It's showing the system with 2 network adapters in a LAG. This allows the swapping of a $12 and $350 cable w/o interruption in playback. That is as a listener, if you think you can tell the difference, this should allow you to swap and follow the bouncing ball. Alternately this will allow me do administer a single blind test.

I often understand why folks get offended when someone makes pronouncements & asserts to them what they can and cannot hear, and/or what they've experienced. Even a 3 component, analog-based, system with associated cables, (and/or) vibration mitigation: interacting in a certain unique room, - is too complicated to predict the nature of the experience.

 

The thing that is at play here with any particular ethernet cable is far more than a simple packet transfer under the OSI model.

 

Just one of the others is Galvanic Isolation. Several developers/manufacturers have demonstrated (with ample evidence) That "computer industry" isolation devices inserted into the "system" yield SQ benefits in high performance audio system; where these devices yield little benefit to a simple file transfer.

 

You do not list your system, nor do you identify any testing that you've performed.

 

Finally, I would ask you what others here, (and indeed has already been expressed in this thread), may want to ask, - do you think that the significant amount of listeners who hear a difference between ethernet cables in their system are all lying?

[Ralf11]

I'd like to look at the studies that were demonstrated (with ample evidence). Do you have a citation?

 

re your last para. - No, not lying; but many are victims of confirmation bias. No controls, means no valid test.

 

Then there is the mechanistic approach - if there is no way something could make a difference based on our comprehensive understanding of electronics, then one is either blowing smoke or are in line for a Noble prize

 

all bets are off after jan. 20 tho. - anything goes

[Albrecht]

I'd like to look at the studies that were demonstrated (with ample evidence). Do you have a citation?

 

re your last para. - No, not lying; but many are victims of confirmation bias. No controls, means no valid test.

Then there is the mechanistic approach - if there is no way something could make a difference based on our comprehensive understanding of electronics, then one is either blowing smoke or are in line for a Noble prize

 

Hi,

Thanks for answering. Certainly some tests are better than others. Comparing 10 cables is better than comparing 2. What constitutes "valid" or validity-of can't even be addressed if no comparisons are done at all. I don't know of anyone who has tried to assert "sounds better" who hasn't conducted a comparative test. When comparing two cables, - there is always a "control"

 

""Then there is the mechanistic approach - if there is no way something could make a difference based on our comprehensive"

 

This almost never comes into play in real life, - can you think of an example? Certainly with the bandwidth specs alone between a CAT7 & CAT3 cable, will tell you that there are dramatic differences in the cables. Again, there is no electronic measurement that takes the place of the final experience of our hearing processes. I defy the notion that our experiences, and our hearing is so flawed, (and flawed more than our other senses) that they cannot be trusted. The essence of science is controlled observations.

You are correct about the application of "confirmation bias," - but the many here, applies to naysayers who assert that there can be no difference outside any aposteriori investigation.

[plissken]

I often understand why folks get offended when someone makes pronouncements & asserts to them what they can and cannot hear, and/or what they've experienced. Even a 3 component, analog-based, system with associated cables, (and/or) vibration mitigation: interacting in a certain unique room, - is too complicated to predict the nature of the experience.

 

I hate it when people don't understand how networking works but continue to express expertise.

 

I hate it when people talk about some study somewhere that presents as factual proof but yet links to said study(ies) are never forthcoming.

 

I hate it when people conflate non-realtime data delivery with being analogous to streaming audio in real time.

[Albrecht]

I hate it when people don't understand how networking works but continue to express expertise.

 

I hate it when "preachers" draw wild, unsubstantiated conclusions about systems & people outside experience and science.

 

I hate it when people "play God" and assert that people can and can't hear something.

[The Computer Audiophile]

Enough nonsense. Meaning - Stop bickering.

[plissken]

I hate it when "preachers" draw wild, unsubstantiated conclusions about systems & people outside experience and science.

 

I hate it when people "play God" and assert that people can and can't hear something.

 

I hate it that audiophools can't figure out the this is data and not audio. I hate that they can't figure out that Ethernet is a highly engineered, non-realtime system but feel obligated to describe it in real time, analog, terms.

 

I hate it that every time I offer the 'night and day', 'difference is readily apparent', $2000 to prove it that their claims suddenly vanish.

[plissken]

Enough nonsense. Meaning - Stop bickering.

 

Which nonsense? The nonsense about Ethernet cables having sonic attributes? Why can't some of this BS simply be verboten here. At a computer based audio forum?