Search This Blog

Saturday, August 1, 2015

An Ars Technica "Audiophile" Testing FAIL


Note the audio files on the Synology
(For more than fifteen years I worked with a commercial system I developed that delivered massive amounts (terabytes) of NAS data in real time in a commercial printing scenario.  During that time there was not, as far as I know and we handled all the support, a single data error related to the streaming of data from the NAS.)

I stumbled upon and started to read an Ars Technica article called "The Audiophile's Dilemma" - I thought at first it was about whether you could hear the difference in audio cables, e.g., a speaker or microphone cable.  (Some people claim to be able to hear, for example, that a gold-plated connector sounds "better" than one that is not gold plated.)

Always an interesting read.

But this article was different...

The idea was whether or not you could hear the difference using an expensive ($340 USD) networking cable.

But not by sending audio over it!

Instead, the cable was being used as a network cable hooked to a standard ethernet switch.  Not passing audio over the cable but simply file data (SMB-style block transfers between an NAS and a computer one supposes).

So, according to the article "The test setup had the Synology DS215j connected by a standard Ethernet cable to the switch and the laptop connected to the same switch by the cable under test" and a "Dell M2800 laptop to serve as a listening station."

The Synology is a box (see this) containing storage, in the case of this test two "Digital WD Red 1TB WD10EFRX" drives.

So effectively we have a laptop with attached storage via the "cable under test" through a switch to the Synology.

The extracted audio (to be listened two comparatively) was a 30 second clip from a CD.

CD's are typically 44.1kHz sampled so we are talking about a 1.5Mb of audio data (x2 for stereo, though according to the above image we've got about 5.5Mb of audio data...).

In any case one supposes that a Windows audio player is being used to play these files for the comparison test (no mention I could find of which one or how it was set up).

So, let's pause right here for a second and think about this...

We are going to play audio files on a laptop from a connected network storage.  Network storage connected via a 1Gbit switch ("One Netgear ProSAFE 5-port gigabit Ethernet switch, model GS105NA" according to the article).

The drives are rated 150Mb/second and the Synology around 111Mb/sec (see this).

We are supposedly going to compare the "audio quality" of data transferred via different network cables used between the network switch and the laptop.

I guess those involved in this, Lee Hutchinson (the author from Ars and the James Randi of the James Randi Educational Foundation (JREF)), imagined they were "playing" the audio files over the switch through "cable under test" in such a was as to potentially "hear" the difference in cables.

However, this seems to me to be, well, basically, impossible.

For one, the entire 5Mb of audio, given the configuration described, would move from the Synology to the laptop in, say, 50 milliseconds (50ms).  Most likely (and this part was not described in the article) the audio player would open the file (or have it held open) and the OS (Windows I supposed) and/or the audio player would likely buffer the file data (some or all of it).  This means that once you clicked on play the audio player would (worst case) load the entire file into memory and then start playing it.

This is not described by the article though it seems quite unlikely that the audio player is reading data one byte or even one block at a time.

(The NAS probably looks like a local drive to Windows and the audio player so both would assume that it was "local", i.e., a local disk, and simply assume the transfer to memory would be immediate as opposed to playing a file via a WiFi connection where there would be latency.)

Nor should a configuration like this be confused with network "streaming" where audio bytes flow as needed across network connection.

NAS tries to make the storage look and act like a local, fast disk which means that its running SMB-like protocols with block transfers, not streams of audio "bytes."

Further, the actual procedure described of "switching cables" and playing audio does not describe whether the audio was "refreshed" (or flushed) each time, i.e., once loaded in the audio player and the cables were being switched did the audio even get read from the NAS after the first time it was loaded and played (things like OS buffering, NAS architecture, etc. all come into play on this).  The entire clip, for example, (tiny at 5.5Mb) may have just sat on the audio player (or in the OS disk buffers) after the first use.

The file sizes involved are very small relative to OS and NAS buffering sizes.  We also don't know the frame sizes used for networking and its entirely possible the entire file moved across the network in only a few frames at 1Gb/sec.

Audio players typically buffer data when clips start playing to ensure that there is no skipping or jitter - how big are the buffers in this case?

Regardless of these points the move of the data from the NAS to the laptop is basically guaranteed to be error free by the networking protocol.

Without extensive knowledge about what was done and, more importantly, the specific details of the audio play, OS, drivers, etc. etc. there is no way to know what was happening for sure other than to say the supposed "quality" of the cable is not an issue.

Given my experience with these sorts of things what they imagined they were doing and what actually happened are certainly two different things entirely.

Then there is the issue of what people appear to think is happening with "interference" on the cable.

Twisted pair ethernet is the physical connection between two points in a network.  The layers above the connection handle ensuring that data moving over the network occurs without error.

And this is key.

If audio data were moving over a twisted pair then one would imagine that interference would matter (and could be "heard" by a listener).

In this case we are sending blocks (most likely SMB-style blocks of file data) from one point to another.

If twisted pair ethernet were at all noisy at the higher network levels nothing on the planet using twisted pair would work for data.  As for the cable quality - the point of something like twisted pair is to send a differential signal which is likely to be more immune to noise than an unbalanced signal.  Secondly, ethernet by nature is not "clean" - frames interfere by design on the wire.  The purpose of the higher protocol levels is to ensure that the delivered data is clean and error free.

These fools even write about how the expensive twisted pair cables are "directional."  Apparently it matters which end you plug in where (perhaps at the limits of 1 Gb/sec transfer speeds but not for moving a paltry 6Mb of data around).

So these poor bastards seem to be confusing "quality of cable" in a NAS-style data role with "sound quality."

They appear to have no idea what-so-ever about audio, NAS, audio and audio software, buffering, how NAS works, how OS software works, nothing!

They are not testing what they think they are testing.

And this is sad.

Poor old James Randi is sucked into this debacle of stupidity right along with the author.

So the idea was that the author and Ars and, I guess James Randi, believed that they were somehow testing the audio quality of data over a network cable when in fact they were testing nothing of the sort.

When I was a boy I was always interested in science and technology.  I would conduct what I thought were "experiments" and showed amazing things.

However, whenever I showed these experiments to "grown ups" they would always point out how what I thought was going on was in fact merely what I had fooled myself into believing.

Sadly, today this would be appear to be what a lot of science has become.

Tests so ill though out that they are meaningless - yet, as in the case of this article - still presented as meaningful.


No comments:

Post a Comment