Steven Plaskin of Audiostream recently
reviewed a CAT8 cable and ascribed all sorts of timing, phase, and room dependent platitudes to it.
The issue they don't understand is that this is Data cabling. Not audio. It's not even real-time.
Do different Ethernet cables affect your sound quality?
There has been a lot of Internet debate as to the sound quality that various Ethernet cables exhibit. Some Audio journalists have claimed that Audiophile Ethernet cables improve streaming playback of music in multiple and varied configurations and differing scenarios. Descriptions include: “The perceived differences between the Vodka, Diamond, Cinnamon, and Cat. 5 cable are plainly apparent and easy to hear(1)”, “
One Million Bicycles from Katie Melua’s CD
Live At The O2 Arena opens up and suddenly the public plays a much more important role at the beginning and end of the song” (2), “…chin, meet floor. There was a difference: more micro-dynamic attack, more intensity(3)”, “On paper, Ethernet cables shouldn’t matter. In reality to anyone in attendance that day in Denver, they do. For this commentator, here were results from two different shows, each with different rooms and different hardware configurations(3)”.
How do we test the claim?
Will using a certified CAT6a cable of ~$10-15 cost vs comparatively expensive boutique cable show statistically significant results in terms of difference? Will an advertised audiophile Ethernet cable be reliably chosen 14 out of 15 randomized changes as the 'better' sounding cable in a controlled Double Blind Test?
All reasonable objections from the Audiophile community need to be addressed. You have to prudently answer any criticism that components in the audio chain is in question. That is you have to use components of known brain trust value by the community at large that can't be picked apart by a person that doesn't hit the 93% threshold and
also bolsters the person that did.
The evaluation apparatus is comprised of two key sections: Computer playback systems plus interceding switches and cabling and the audio stack that starts with the USB DAC, then amplifier, then speakers and some nominal room treatments. Our other components are music sources of well mastered audio. High bit-rate encoded files will be used when possible either 24/96 or 24/192 sources.
And finally testing has to take place at a venue for audio enthusiasts to get as close to an audibility aware audience as possible. Here is the proposed evaluation protocol:
- The computer portion will consist of a Server/Client model. Switch will be a CISCO SG200 or other comparable managed switch. It will be configured for LACP (Link Aggregate Control Protocol).
- Server will be dual homed (meaning two NICs or dual adapter) and the client computer will be dual homed (two NIC's) in a LAG (Link Aggregate Group). NIC cards will be Intel PCIe adapters. Either two individual or one dual NIC.
- Ethernet cables will consist of BJC 6a and Audioquest Vodka or Wireworld CAT8 (if they pass spec).
- The Client OS will be Windows 8.1 with JRiver Media Player with 10 second pre-buffer. Server OS will also be Windows 8.1 with SMB as the transport protocol.
- LAG / NIC Teaming plus JRiver ensures that cables can be switched with zero break in audio playback. LAG will use the Intel teaming feature.
- USB DAC will be connected with AQ Carbon or comparable USB Cable. Speakers will use MIT EXP2 cables.
- The testing procedure will be Single Blind Testing. That is the participant will not know what cable is in use.
- Each session will represent ~20 minutes and 15 possible changes. Participants will be audibly queued that an interval has been reached. This does not mean that a change has indeed been made. 40 minute sessions are to ensure there isn't listener fatigue. Up to 3 participants will listen at a time.
- Each listening interval will be approximately 1 minute long with three 20 second primary tracks followed by 15 second interval track during which possible swaps of cable could be made. This will loop and repeat 14 more times.
- Participants will be given a sealed and labeled envelope prior to their session that lists the predetermined cable swap order that they can compare their results to afterwards. This will be handed out by the person/s performing the cable swap. Neither the practitioner or participant will know which predetermined envelope will be handed out.
- Participants will get a 6 minute sighted session prior with the knowledge of what cable is currently in use.
- Each session will have a different randomized set as it pertains to potential cable swap.
- Sessions will be video recorded.
- Monetary inducement of some form should be arranged. This helps increase the applicant pool. Listener would pass through two sessions to mitigate the potential of random guessing.
What do we know about Ethernet?
First off there needs to be a general understanding that structured cabling is encompassed by an engineering standards body. The standard is the IEEE 802.3(4). That is: Every aspect of data cabling is strictly engineered and controlled for.
For any modern Base T cabling an eight conductor twisted pair cable terminated with an 8P8C connector (or other 'in scope' of specification termination) by and of itself is not an Ethernet cable. It may look like an Ethernet cable. It may pass data. If the cable doesn't pass spec then it is not an Ethernet cable. With that understanding we can then focus on cabling that passes specification. This type of cabling is going to be the most commonly implemented networking solution as the majority of high quality streamers from the likes of Bryston, NAIM, Linn, NAD, Oppo, Cambridge Audio, etc... all support wired Ethernet
Another point of confusion that some cable vendors don't help in clearing up is the fact that there is no official CAT7(5) specification. CAT6A is the last ratified specification and is good to 10GB.
The CAT7 specification may not even make it to light of day with the TIA standards body looking to go directly to CAT8. The 8P8C connector is not supported under the current working CAT7 standard. Choices are GG45 which maintains backwards compliance but adds an additional 4 conductors or a totally new Tera connector.
What do I need to know about Ethernet as it pertains to my enjoyment of audio?
Ethernet is non-realtime / iso-synchronous, packet based, windowed, error checked (TCP), error corrected (if need be) by re-transmit (TCP), and fixed frequency. It is electrically isolated by the Magnetics Package in the port and CMNR. This is among other things that the specification calls for. All that this means is Ethernet is extremely noise end error resistant by design.
Also there is no audio clocking data on Ethernet. It is time insensitive in this regard. For Gbit applications it features a 25Mhz clock multiplied out to 125Mhz.
In other words timing oddities (Jitter) does not matter and here is why:
Gigabit networking is common, affordable, and easy to implement. A 700MB 16/44.1 encoded album can be transferred from point A to B in ~5-7 seconds. A 2.5GB 24/96 album is less than 30 seconds. This for an entire album that could be 45-60 minutes long.
If a buffer was large enough one could conceivably start playback, wait 30 seconds, unplug the network cable and enjoy uninterrupted audio for the duration.
What does a properly functioning Ethernet cable look like?
The only way to know if you have a true Ethernet cable is to certify it or purchase it from a vendor the provides certification. To an analyzer it looks something like this:
For a key to decoding what the above measurements mean:
http://www.bluejeanscable.com/networkcablereports.htm
Common Myths:
1 Ethernet is a packet protocol that is intended for the transmission of non-isochronous data, or data that is insensitive to time delay. When we transmit isochronous (time delay sensitive) data over Ethernet we are using it for a purpose for which it was not designed.(6)
2 The file statically stored on disk or in buffer can contain jitter/noise introduced from the transmission over the Ethernet cable.(7)
3 The 1 and 0 written to disk or buffer/cache are some how more prominent with a better cable. I.E. Fast Transient Response)
So what are we to make of the myths surrounding Networked audio?
Steve Nugent of Empirical audio has a rather great write up that not only covers Networked audio but other transmission formats as well. (9)
“
Networked audio (Ethernet), both wired and WiFi is a unique case. Because the data is transmitted in packets with flow-control, re-try for errors and buffering at the end-point device, it is not as much of a real-time transfer as USB, S/PDIF or Firewire. The computer transmitting the data packets must still keep-up" the pace to prevent dropouts from occurring, but the real-time nature of the transfer is looser. Unlike with other protocols, there can be dead-times when no data is being transferred. Networking also avoids the use of the audio stack of the computer audio system since it treats all data essentially the same. This avoids kmixer on XP systems and the audio stacks on Mac and PC Vista. Because of the packet-transfer protocol of Ethernet and data buffering at the end-point, the jitter of the clock in the computer is a non-issue. The only clock that is important is the one in the end-point device. Examples of end-point devices are: Squeezebox, Duet and Sonos. This would seem to be the ideal situation, which it certainly is. The only problem that can occur is overloading the network with traffic or WiFi interference, which may cause occasional dropouts. The problem for audiophiles is that the majority of these end-point devices were designed with high-volume manufacturing and low-cost as requirements, with performance taking a lower priority. As a result, the jitter from these devices is higher than it could be. It should be the lowest of all the audio source devices available.”
If there is a more succinct and to the point paragraph out there regarding networked audio and jitter induced effects I haven't read it to date. Combining this with the best practice guidelines uncompromising audio is easily achieved with commodity products. The jitter and EMI arguments can be adequately addressed in real engineering terms.
Transient response isn't going to matter. Ethernet is error checked on many levels. Including Packet and Frame. CRC32 will only miss 1 out of 4 billion bytes (unaccounted error).
Timing variance in a non-real time system is also being considered. The facts are that when data fills a buffer the jitter that was on the transmit line into the buffer matters not. It ceases to exist.
So in a nutshell the only jitter that matters is when the timing variance is large enough to cause a buffer under run. In this scenario music playback will halt.
Consider that Ethernet is actually better than real time analog due to the very fact that it is impervious to timing errors (barring complete failure of equipment). That is in a properly running environment keeping the the audio packet data in the Ethernet domain as close to the reproduction hardware is the goal most enthusiasts should be really concentrating on.
See this YouTube video showing the non-realtime nature of audio data over Ethernet. Keep in mind this is on a single 1.4Ghz Celeron CPU based laptop with rather plebeian 54Mbps wireless Ethernet playing a 24/192Khz file.
Look to the left hand side and you will see periodically the Kbps rate go down to Zero but audio is still playing.
The Windows OS will even power down the NIC when data isn't flowing to conserve power (we aren't talking about sleep mode either):
But what about EMI noise?
EMI noise is a problem when present and the DAC can't isolate / reject said noise.
Siemons testing shows that even UTP CAT6 shrugs off 18v/meter noise and considers heavy industrial environments to operate about the 10v/meter mark. They list CAT6 as having noise immunity up to 30Mhz.
In a T.I. (Texas Instruments) white paper “Reducing Radiated Emissions in Ethernet 10/100 LAN Applications” common approaches are detailed in how to properly engineer a data cabling solution (outside of using T.I. PHYTER products). (10)
Here are the key take-aways that end users can implement.
- Use high quality CAT5E or better cable in implementing network systems. If possible use shielded cable.
- Use shielded network connectors connected to a decoupled chassis ground plane. Other shielding strategies require great care as they can introduce problems if not implemented correctly.
- Use a shielded connector on the network interface PCB. The shielded connector should be connected to a PCB chassis ground plane that is decoupled from PCB system ground.
- Keep low voltage signaling and power lines separated.
One item of particular note in the T.I. white paper: Power supply current can be considered single ended in a lot of installations. So the use of -60 /0/ +60 source of power could be implemented as another step in the proper engineering of a structured cabling networked system.
So in a nutshell: Use quality, shielded cabling (BJC is a solid choice), proper termination, decoupled chassis ground, a network switch with shielded ports and tied to chassis if possible, and if again possible differential power supply. Noise suppression is about proper engineering approaches. Not overpriced cabling.
Please note that the white paper is talking about the emissions that originate from all copper based Ethernet cabling. This is especially true when running many cables in a bundle. Something not often seen in a home environment so UTP cabling is more than adequate for home installations.
What do different 'Ethernet' cables look like audio frequency wise?
Archimago has done some well thought out testing and published these results(11):
FR Response:
Noise level: Slight 60Hz hum measured downs at -115dB at it's worst.
IMD:
Stereo Crosstalk:
Conclusion
Ethernet is a data only standard. It's doesn't matter what is being passed across the line as long as the need on the receive side isn't greater than the sustained through put.
Ethernet is also a pedal to the metal standard. It will give you the max data rate it can on every single transfer. There is currently no measurement data to support audible differences in Ethernet cabling as it pertains to a consumer / residential environment. So claims need to be measured with the devices that the claimants have used to evaluate and make such claims: Ears and solid audio equipment.
These revelations to improved performance have taken place at multiple venues, not just the claimants own setup. It's also been deduced with audio tracks supplied by the vendor at these venues. So we see no issue with the test setup since it is going to trend along the lines of the vendors setup, in part, that such claims where predicated on.
References:
- http://www.audiostream.com/content/audioquest-vodka-ethernet-cable-and-diamond-ethernet-cable
and
http://www.audiostream.com/content/wireworld-starlight-cat8-ethernet-cable
- http://www.the-ear.net/review-hardware/audioquest-pearl-and-cinnamon-ethernet-cables-digital-interconnect
- http://www.digitalaudioreview.net/2014/12/from-munich-to-denver-with-audioquest-ethernet-cables/
- http://www.ieee802.org/3/
- https://awcwire.wordpress.com/2013/10/15/the-cat7-cable-debate/
- http://forum.polkaudio.com/discussion/comment/2052465#Comment_2052465
- http://www.whatsbestforum.com/showthread.php?14980-Does-a-file-with-jitter-keep-the-jitter-when-saved-to-a-hard-drive
- http://forum.polkaudio.com/discussion/comment/2062499/#Comment_2062499
- http://www.positive-feedback.com/Issue43/jitter.htm
- http://www.ti.com/lit/an/snla107a/snla107a.pdf
- http://archimago.blogspot.com/2015/02/measurements-ethernet-cables-and-audio.html
