Jump to content
IGNORED

Ars prepares to put “audiophile” Ethernet cables to the test in Las Vegas


Recommended Posts

Okay, that's fine. But it also limits the conclusions you can draw from the test: you can draw a conclusion that most people can't hear the difference but not that the cables don't make any difference.

 

That's standard for any test of a null hypothesis. If you can produce a statistically robust counterexample (one person who can pass the test multiple times, or large numbers of people that can past the test a single time), you have evidence that the null hypothesis is wrong.

 

If not, you cannot really conclude anything about the veracity of the null hypothesis (apart from the observation that you haven't yet refuted it). There is no inductive proof, only falsification via counter-example.

Link to comment
plissken,

 

Just curious . . . have you ever listened to an Audioquest (or similar "audiophile") ethernet cable?

 

Joel

 

 

Well, that didn't take long.

"People hear what they see." - Doris Day

The forum would be a much better place if everyone were less convinced of how right they were.

Link to comment
That question should be asked every time as most of the time, at least in my experience, those who believe the audiophile cables don't (and can't) make a difference, have never heard them.

 

Joel

 

For the record I've also had Pangea PC's on loan.

 

I'm not sure why there is doubt where a properly implemented network is involved that adding a higher cost cable isn't going to start yielding improvements.

 

You guys and gals are all, hopefully, computer people. So I have a few questions:

 

JRiver buffers the network stream. It's default is 6 seconds and this is easily changed. So change it to 10 seconds.

 

Plug a cable in and play for 2 seconds on a GB network. At 90-100MB/second how long do you think the buffer is going to take to fill?

 

So you now have a 10 second buffer on the system. Pull the BJC, TrippLite or other certified cable. Plug in a $350 cable. Continue play.

 

From WHAT point is the audio going to be improved?

Link to comment

Some of us . . . many of us, myself most definitely included, hear positive differences with audiophile cables. I even use an audiophile sata cable in my PC and a Corning optical cable to connect my hard drive to my PC. I've heard meaningful improvements using both cables.

 

One of the great things about this hobby is that it affords us the opportunity to be surprised. Just because something doesn't seem like it should make a difference doesn't mean it won't.

 

I'm far from the most technically competent on this (or likely any) forum. However, my limited understanding is that cables often pickup interference from a variety of sources which can affect the way in which computers can read the data they receive via these cables. And I'm not only talking about digital accuracy, resulting in error correction in some cases, but also issues with latency. Others can explain this phenomenon far far better than I ever could.

 

Regardless, these cables have increased my enjoyment of this hobby. I'll listen first and ask questions later. Those who don't are likely penalizing themselves by believing they know more than they really do.

 

Joel

Link to comment

Just to add my 0.02 pesos to a very touch subject - I am firmly in the cable is cable side - however one thing that I ask from my cables is quality build - cheapest ones I have bought have broken and that is annoying - I will go as high in price as Blue Jeans cables - but no more. Quality on those is excellent.

thnx!

 

v

Link to comment
A slight correction. You can draw a conclusion that most of the people didn't hear a difference, but not that the cables don't make any difference.

 

Unless you have a population in mind and reason to believe that the population in the study was representative you are limited to conclusions about the people who actually participated. From the conclusion that they didn't hear a difference, it is not reasonable to conclude that they couldn't hear a difference under different circumstances. The result of these experiments are relative to time, place and person and generalization is done at one's peril.

 

Yes but you can't even necessarily draw conclusions about the people who actually participated unless the study has been designed and carried out in a valid fashion. The study needs to start with a question, be designed to have sufficient statistical power to answer the question and then be carried out in a fashion such that the collected data will be valid.

 

Not likely but the results may pique someone's interest enough to do a real study, or not.

Custom room treatments for headphone users.

Link to comment
Some of us . . . many of us, myself most definitely included, hear positive differences with audiophile cables. I even use an audiophile sata cable in my PC and a Corning optical cable to connect my hard drive to my PC. I've heard meaningful improvements using both cables.

 

That's all fine and well but what about my question?

Link to comment
That's all fine and well but what about my question?

 

As best I understand, any time you plug a cable into a computer you introduce the possibility of adding electrical noise into the system . . . even if no signal is being played.

 

That noise can affect the accuracy of the operation of the computer.

 

Joel

Link to comment
As best I understand, any time you plug a cable into a computer you introduce the possibility of adding electrical noise into the system . . . even if no signal is being played.

 

That noise can affect the accuracy of the operation of the computer.

 

Joel

 

Yes to the first part, but no I think to the second. Unless the noise is of such magnitude as to cause bit (data) errors. Hypothetically, the noise can affect the speed and timing of data transmissions, which is for all intents and purposes, they same as saying adding jitter to the signal.

 

-Paul

Anyone who considers protocol unimportant has never dealt with a cat DAC.

Robert A. Heinlein

Link to comment

 

That noise can affect the accuracy of the operation of the computer.

 

Joel

 

If that was the case, the results of computations would differ, depending on the cable you have plugged into a computer.

 

Fortunately, this doesn't happen.

Link to comment
Fair enough.

 

Couldn't a cable affect latency though?

 

Joel

 

That is easy enough to test. Look for packet dropouts.

 

I do think that a cable can transmit/affect noise on the receiving system, either by transmitting noise along with the bits, or by making the receiving interface "work harder". For example less noise with "green Ethernet" and shorter cable runs.

Custom room treatments for headphone users.

Link to comment
I've seen an Audio Journalist specifically state they heard a difference in Ethernet cables at an AQ dog and pony show with a room full of other enthusiasts that heard a definitive difference.

 

Same with Nordost PC's. All at a show.

 

So wonder no longer.

 

Sorry but the excuses don't hold water. There is a very large and contradictory bunch in the Audiophile community.

 

Totally different environment that being on a stage and being tested using ABX. You are comparing apples and oranges. I personally doubt I could perform adequately under the conditions that ARS is using for their test.

Main listening (small home office):

Main setup: Surge protector +>Isol-8 Mini sub Axis Power Strip/Isolation>QuietPC Low Noise Server>Roon (Audiolense DRC)>Stack Audio Link II>Kii Control>Kii Three (on their own electric circuit) >GIK Room Treatments.

Secondary Path: Server with Audiolense RC>RPi4 or analog>Cayin iDAC6 MKII (tube mode) (XLR)>Kii Three BXT

Bedroom: SBTouch to Cambridge Soundworks Desktop Setup.
Living Room/Kitchen: Ropieee (RPi3b+ with touchscreen) + Schiit Modi3E to a pair of Morel Hogtalare. 

All absolute statements about audio are false :)

Link to comment
Totally different environment that being on a stage and being tested using ABX. You are comparing apples and oranges. I personally doubt I could perform adequately under the conditions that ARS is using for their test.

 

LOL. It's not different. At all. So someone says at a trade show they flapped their arms in a room with 20 other people. Since they were holding the magic feather and they were airborne but put them in a room with 20 other people some where else, give them two feathers and they don't know which is magical and they can't do it?

 

You HAVE to admit to yourself that it just may be psychosomatic.

 

And now to add on top of this you are clairvoyant as well since the testing protocol hasn't been published as of yet.

Link to comment
As best I understand, any time you plug a cable into a computer you introduce the possibility of adding electrical noise into the system . . . even if no signal is being played.

 

That noise can affect the accuracy of the operation of the computer.

 

Joel

 

Then how do computers perform complex computational operations w/o error. How does NASDAQ, NYSE, QuickBooks, Excel, MySQL server run huge datasets?

 

So you are you totally dismissing a possibility that you could plug a certified CAT6(a) shielded and foil twisted pair cable of the $12 variety in an have zero noise? Noise floor is indeed measurable. IMD is indeed measurable.

 

When you have a no noise scenario upgrading to another cable isn't going to make it less more noise.

Link to comment
Fair enough.

 

Couldn't a cable affect latency though?

 

Joel

 

What do you consider latency?

 

Here is a ping result on my network. It's laptop with a Belden Ethernet cable to Netgear GB switch to my router:

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=3ms TTL=64

Reply from 192.168.0.1: bytes=32 time=2ms TTL=64

Reply from 192.168.0.1: bytes=32 time=2ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=2ms TTL=64

Reply from 192.168.0.1: bytes=32 time=3ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=3ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

 

Here is the result from my laptop to my ReadyNAS:

Pinging 192.168.0.102 with 32 bytes of data:

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time=1ms TTL=64

Reply from 192.168.0.102: bytes=32 time=1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time=1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time=1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time=2ms TTL=64

Reply from 192.168.0.102: bytes=32 time=1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time=1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

 

Sub 1/1000's th of a second response. Just like the absence of noise, how is another cable going to improve on this?

 

If there is no lag, if there is no noise (all easily measurable) then there is nothing you can do with another cable except feel good about it. And that's perfectly acceptable.

Link to comment
Then how do computers perform complex computational operations w/o error. How does NASDAQ, NYSE, QuickBooks, Excel, MySQL server run huge datasets?

 

 

Red herring argument.

 

The idea that the cables could make a difference in the sound of the analog output of the system isn't based on the data being transferred incorrectly. Rather, that the data is transferred correctly but there are other factors (various types of noise) which do affect the analog output, and that these are affected by the use of different ethernet cables.

Main listening (small home office):

Main setup: Surge protector +>Isol-8 Mini sub Axis Power Strip/Isolation>QuietPC Low Noise Server>Roon (Audiolense DRC)>Stack Audio Link II>Kii Control>Kii Three (on their own electric circuit) >GIK Room Treatments.

Secondary Path: Server with Audiolense RC>RPi4 or analog>Cayin iDAC6 MKII (tube mode) (XLR)>Kii Three BXT

Bedroom: SBTouch to Cambridge Soundworks Desktop Setup.
Living Room/Kitchen: Ropieee (RPi3b+ with touchscreen) + Schiit Modi3E to a pair of Morel Hogtalare. 

All absolute statements about audio are false :)

Link to comment

Well, there's latency and then there is latency. In the sample you gave below, it could easily have been that the latency was caused by the processor on device 192.168.0.1 being slower, or much busier, than the processor on 192.168.0.102.

 

In general, I have sub millisecond pings to everything on my home network, save a Roku 3 box. That's true whether they are connected via ethernet, fibre, or wireless.

 

Can you rerun your test just changing out the ethernet cable with one you want to test?

 

-Paul

 

 

 

What do you consider latency?

 

Here is a ping result on my network. It's laptop with a Belden Ethernet cable to Netgear GB switch to my router:

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=3ms TTL=64

Reply from 192.168.0.1: bytes=32 time=2ms TTL=64

Reply from 192.168.0.1: bytes=32 time=2ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=2ms TTL=64

Reply from 192.168.0.1: bytes=32 time=3ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=3ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

 

Here is the result from my laptop to my ReadyNAS:

Pinging 192.168.0.102 with 32 bytes of data:

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time=1ms TTL=64

Reply from 192.168.0.102: bytes=32 time=1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time=1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time=1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time=2ms TTL=64

Reply from 192.168.0.102: bytes=32 time=1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time=1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

Reply from 192.168.0.102: bytes=32 time<1ms TTL=64

 

Sub 1/1000's th of a second response. Just like the absence of noise, how is another cable going to improve on this?

 

If there is no lag, if there is no noise (all easily measurable) then there is nothing you can do with another cable except feel good about it. And that's perfectly acceptable.

Anyone who considers protocol unimportant has never dealt with a cat DAC.

Robert A. Heinlein

Link to comment
What do you consider latency? Sub 1/1000's th of a second response.....how is another cable going to improve on this?

I'm not a disciple of high dollar cables, although I did hear a significant improvement when going from a 10' generic came-with-a-printer-a-thousand-years-ago USB cable to a 1/2M Audioquest Forest (which was probably because the old one was USB1 and suffered mechanical degradation from age and being used many times in many pieces of equipment). However.....

 

Ping rate is a measure of the round-trip transit time between the pinging computer and the target, so it includes transit through all devices, processing, conversions, cables etc and is proportional in some way to the physical distance between termini. IEEE spec RFC254 is the standard for measuring this, and 1 Gb TCP/IP ethernet should have a latency no greater than about 0.1 msec over the physical distance traveled by the signal. Video streaming requires at least a 10Gb net for optimum performance, which is a latency below 50 microseconds. For "low latency applications" like RDMA, the recommended spec is 3 to 5 microseconds. Traditional computer audio is not specifically mentioned in any description of "low latency applications" that I've seen, but AOE (sending digital audio over ethernet without TCP/IP) is treated as one.

 

So technically, 2 to 3 msec latency on a LAN is not low latency. And a range between 1 and 3 msec reflects high variance despite the miniscule durations involved. So I don't have any problem believing that cabling through which latency is cut from 1+ msec to 50 microseconds, with a commensurate reduction in variance, could affect sound quality. Whether it does or not is a different question - but functions like high frequency trading require true, real time latency at or below 5 microseconds. There's good evidence that true low latency improves the accuracy of high volume, high speed trading - so I don't see why it couldn't affect sound quality.

 

Obviously, one would have to stratify the total latency into segments for each component and process. But with top quality equipment, a long CAT run (even in a domestic setting) could significantly change network latency.

Link to comment
Whether it does or not is a different question - but functions like high frequency trading require true, real time latency at or below 5 microseconds. There's good evidence that true low latency improves the accuracy of high volume, high speed trading....

 

OT - have you read Michael Lewis' "Flash Boys"?

One never knows, do one? - Fats Waller

The fairest thing we can experience is the mysterious. It is the fundamental emotion which stands at the cradle of true art and true science. - Einstein

Computer, Audirvana -> optical Ethernet to Fitlet3 -> Fibbr Alpha Optical USB -> iFi NEO iDSD DAC -> Apollon Audio 1ET400A Mini (Purifi based) -> Vandersteen 3A Signature.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...