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

[plissken]

Packets entering a network don't all reach their destinations. The commonest cause of packet loss is network congestion - they're dropped if bandwidth won't accommodate them. I never said they don't make it through one continuous cable. I also said (about a year ago, it seems...) that if an Ethernet cable did introduce latency of sufficient duration and with sufficient variance, I believe it could (not does......theoretically could) affect sound quality. That's what seems to have kindled the flames.

 

I'm profoundly sorry I ever posted, guys & gals. I'll think twice before doing so again. Now my wife & I are going to watch Fellini's 8 1/2 to restore our sanity.......

 

Jimminy Cricket. We are talking about home networks!

 

I now understand the issues you faced getting good audio out of your system...

[plissken]

My experience is that most people, even otherwise good engineers, haven't a clue when it comes to the important details of clocking in systems or networks of systems that involve multiple clocks. There are few people who can get these things right, and they do so because their fingers have been burned. It gets worse when one starts dealing with real time applications running over computer networks.

 

I'm sorry, but most of the discussion here is not on a competent level when it comes to computer network architecture and protocols, nor would I expect it to be on an audio forum. However, reasonable people ought to know when they don't know. I am not going to say any more on this subject.

 

Huh. Never seemed to have a problem installing black burst generators (also called Time Based Correctors) when connecting $50,000 Panasonic D1 1" decks back in the day.

 

I agree there are a lot of people that are convinced they know what they are talking about.

[plissken]

Ok. Let me put is this way:

 

I'm going to be attending Axpona next April.

 

I'll bring a setup:

 

Server and Client, Router, Switch, Fiber, and Copper NIC, DAC, Amp and Speakers.

 

Feel free to attend. If you can pick out which is which 14/15 blind I'll give you $500. You pony up $100. Should take about 15 minutes.

 

Put all your theories and expertise where your mouth is. I'm willing to bet on my expertise vs yours.

[mmerrill99]

It's interesting that you appear to be talking about the computer (sending) side of the system rather than the receiving (DAC) side. Why would having overhead left on a Celeron tell us very much about the electrical activity of an Ethernet receiver chip on a board in another piece of equipment?

Yes, it's an interesting but not unusual blind spot that many seem to be afflicted by

 

I'm certainly not an expert and could easily be wrong, but it seems to me there may be parallels between Ethernet and USB in terms of feeding a buffer and having a receiver chip on another board. For the USB situation there's a fellow who says he thinks the electrical activity of the receiver chip is important. This fellow knows something about computers, since his job for 25+ years has been to help design chips.

 

Now he may not be right about the USB thing, or I may be wrong about Ethernet being similar, but I wonder if it's not at least worth some thought.

Well packet noise is a well known issue in any packetised comms protocol at the electrical level. USB has 8KHz (& harmonics at 16KHz, 24KHz, etc) noise spikes due to the 125uS timing of microframes in USB 2.0 high speed comms. Ethernet does not have this regular timing protocol but I've no doubt that there are certain times when there are bursts of packet delivery that are paced which will give rise to temporary noise spikes. This is apart from the possible noise from lowered signal integrity issues.

[mmerrill99]

No making debate points on possible esoteric Ethernet implementations is strawman.

All of the points I made are solid engineering & well known issues which you have failed to take note of or understand in any of your replies.

As I said already - step outside your narrow perspective - think about the system wide electrical implications of networking i.e all the connected elements & the possible implications of noise on the analogue side. It requires mixed signal engineering thinking but it can be done - I'm not saying this from a position of expertise but I know enough to know that I don't know enough!!

[firedog]

Plissken for President!

 

Someone who understands computing.

 

But it's an uphill battle on a site now dominated by audio mysticism.

 

Where is Bob Sherman?

 

JRiver-

Every time you jump into one of these discussions you make some sort of unpleasant/nasty comment that is out of place. If you want to agree with Plissken, great. Why the totally unecessary, out of context, personal jab at Bob?

 

It's great a professional like you participates in the forum. I personally would appreciate it if you'd keep your answers "professional" and not engage in personal or snarky comments.

I find it somewhat offensive, and I know from PMs that I'm not the only one here who feels that way.

 

I've been a JRiver customer for several years, you certainly aren't doing your product branding/image a lot of good with these types of comments.

[plissken]

All of the points I made are solid engineering & well known issues which you have failed to take note of or understand in any of your replies.

As I said already - step outside your narrow perspective - think about the system wide electrical implications of networking i.e all the connected elements & the possible implications of noise on the analogue side. It requires mixed signal engineering thinking but it can be done - I'm not saying this from a position of expertise but I know enough to know that I don't know enough!!

 

Where is any substantiated evidence backing up your proposed issues.

 

From 1991-1998 my primary job was engineering edit suites both Audio and Video. We are talking NLE and DAW, live production sets etc...

 

Panasonic and Sony 1" digital decks, Video Toaster Flyer, Media 100, Time Base Correctors, EQ's, Gates, Compressors, Grass Valley, Extron, Yamaha Professional, JVC, Christie, Bryston.

 

Done GPIO, 485, 232, AES/EBU.

 

The principals haven't changed and all the protocols mentioned are still in use.

 

What I would like to seek clarification is why external clocks are being mentioned for Ethernet data? There's no such thing as Externally clocked Ethernet.

 

FYI I manage a data center that in 2008 consisted of over 300 servers. The team I'm part of now how this down to 50 hypervisors. We have 256GB/sec switch fabric and move around 12TB data a month for customers. The only fiber is backbone on the switch fabric.

 

Everything else is CAT6 GB.

 

The last thing I want to point out is that someone mentioned that the PHY could be causing noise when under stress and polluting the ground plane. I don't even know how to respond to such unsupported conjecture. And it IS conjecture.

 

2nd in the video I shot the 9216Kbps, 24/192 file, I was playing across wireless, if anyone took the time to look instead of speed typing you would see it was a plebian 54Mbps connection and even then it was only doing about 25-27Mbps. About half the signaling rate of the adapter. 50% headroom.

 

Think about it.

 

Sometimes the lesson is only learned when someone puts some skin in the game. See my offer and PM me about Axpona. Time to separate all the arm chair quarterbacks out.

[mmerrill99]

Where is any substantiated evidence backing up your proposed issues......

You mean you don't know about packet noise, skew, crosstalk, common mode noise, differential noise, transformer capacitive leakage in differential signalling systems? You want these facts to be substantiated?

 

BTW, all that's being said by me is that these things need to be considered as part of your evaluation of how Ethernet cables may introduce SQ issues in a connected audio system - I don't know if this actually happens in 99% of systems or at all but they are issues that need to be considered, as Jud said.

 

Your knowledge, judging by your posts, is seemingly unaware of these possibilities & it's just being pointed out to you

[Paul R]

Packets entering a network don't all reach their destinations. The commonest cause of packet loss is network congestion - they're dropped if bandwidth won't accommodate them. I never said they don't make it through one continuous cable. I also said (about a year ago, it seems...) that if an Ethernet cable did introduce latency of sufficient duration and with sufficient variance, I believe it could (not does......theoretically could) affect sound quality. That's what seems to have kindled the flames.

 

I'm profoundly sorry I ever posted, guys & gals. I'll think twice before doing so again. Now my wife & I are going to watch Fellini's 8 1/2 to restore our sanity.......

 

Yeah, you are definitely getting pounded on a bit unfairly.

 

Certainly packets that go into one end of an ethernet network don't all reach their destination 100% of the time, and they do tend to arrive out of order. This becomes more and more true the larger the hetwork those packets have to traverse becomes. But that happens very rarely with typical home networks these days.

 

And in most cases, the software takes care of this and reassembles the packets in the correct order, or requests a retransmission from the source.

 

That is all opposed to audio transmissions over USB where the software does not handle reassambly, out of order packets, and retransmission.

 

Yes, the subject even got me. I do not believe any Cat5 or Cat6 cable that is to spec is going to introduce any latency of any significance what so ever.

 

And yeah, for the record, I am one who finds spending hundreds of dollars on a set of speaker cables a very good purchase. Maybe up to a couple hundred on analog interconnects, and up to about $150 on a USB cable.

 

I do hear a difference between Fibre and Copper network cables, and between a spinning disk and SSD in my setups. Yet to hear any difference between Copper Ethernet and Copper Ethernet cables. The reasons why I might hear those differences are neither solud science or proven anywhere I know of, except in marketing materials.

[Paul R]

You mean you don't know about packet noise, skew crosstalk, common mode noise, differential noise, transformer capacitive leakage in differential signalling systems? You want these facts to be substantiated?

 

BTW, all that's being said by me is that these things need to be considered as part of your evaluation of how Ethernet cables may introduce SQ issues in a connected audio system - I don't know if this actually happens in 99% of systems or at all but they are issues that need to be considered, as Jud said.

 

Your knowledge, judging by your posts, is seemingly unaware of these possibilities & it's just being pointed out to you

 

Actually, I am not so sure the average audiophile needs to consider those subjects at all, so far as Ethernet cables go. You are building up a case that all those subjects can affect the sound of music data delivered over an Ethernet cable.

 

It is still just a theory, and one that should require, as our objectivist friends say, extraordinary proof. That is a very reasonable and solid statement. The one place it really becomes a possible issue in my opinion, is when a DAC is connected directly to an Ethernet cable.

 

I sm speaking to a home network environment here. One where wireless is going to be more common than ethernet cable, and where the evil influence of microwave ovens and plasma tv's is of much more concern sound wise than any possible impact of ethernet cables.

[Paul R]

It's interesting that you appear to be talking about the computer (sending) side of the system rather than the receiving (DAC) side. Why would having overhead left on a Celeron tell us very much about the electrical activity of an Ethernet receiver chip on a board in another piece of equipment?

 

I'm certainly not an expert and could easily be wrong, but it seems to me there may be parallels between Ethernet and USB in terms of feeding a buffer and having a receiver chip on another board. For the USB situation there's a fellow who says he thinks the electrical activity of the receiver chip is important. This fellow knows something about computers, since his job for 25+ years has been to help design chips.

 

Now he may not be right about the USB thing, or I may be wrong about Ethernet being similar, but I wonder if it's not at least worth some thought.

 

Yep, but there is a fundamental difference. Most, if not all ethernet adapters take a big memory dump delivered often by direct memory access, and handle all the details of packetizing and sending or receiving it. The software TCP stack has little to do with the hardware side, timing, etc.

 

Very different with audio USB -where the processor has to do a great deal of that work.

 

USB transmissions have a much greater impact on CPU activity than do Ethernet transmissions.

 

You could say Ethernet is rather smart, while USB is quite dumb, and has to be told how and when to do most things.

[mmerrill99]

Actually, I am not so sure the average audiophile needs to consider those subjects at all, so far as Ethernet cables go.

Average audiophile, no but when someone posts on a forum that something is impossible it is worthwhile pointing out the possibilities, no?

You are building up a case that all those subjects can affect the sound of music data delivered over an Ethernet cable.

I'm just suggesting possible mechanisms whereby SQ may be affected

 

It is still just a theory, and one that should require, as our objectivist friends say, extraordinary proof. That is a very reasonable and solid statement. The one place it really becomes a possible issue in my opinion, is when a DAC is connected directly to an Ethernet cable.

Sure it's just a theory, I wasn't suggesting anything else - just pointing out the possibilities.

 

I sm speaking to a home network environment here. One where wireless is going to be more common than ethernet cable, and where the evil influence of microwave ovens and plasma tv's is of much more concern sound wise than any possible impact of ethernet cables.

Yes, WiFi is another can of worms

[jriver]

JRiver-

Every time you jump into one of these discussions you make some sort of unpleasant/nasty comment that is out of place. If you want to agree with Plissken, great. Why the totally unecessary, out of context, personal jab at Bob?

It's nothing personal. Bob just likes to post odd videos in response to my posts.

 

I didn't intend to make an unpleasant or nasty comment. I'm just in full support of plissken's attempt to explain how Ethernet and digital audio work.

It's great a professional like you participates in the forum. I personally would appreciate it if you'd keep your answers "professional" and not engage in personal or snarky comments.

I used to participate more when the forum was more balanced. It's now became, in my opinion, a place where grossly inaccurate information is commonly passed from person to person without regard to the basics of computing.

I find it somewhat offensive, and I know from PMs that I'm not the only one here who feels that way.

I'm sorry if I've offended you.

I've been a JRiver customer for several years, you certainly aren't doing your product branding/image a lot of good with these types of comments.

As I said, I'm posting in support of someone who is, in my opinion, speaking truthfully about a subject he understands.

 

If that makes me a heretic, then so be it.

[mmerrill99]

Here's a measurement of 8KHz USB packet noise for all objectivists - obviously not Ethernet packet noise

[plissken]

You mean you don't know about packet noise, skew crosstalk, common mode noise, differential noise, transformer capacitive leakage in differential signalling systems? You want these facts to be substantiated?

 

I know what these items are and I am saying you are correlating this to audibility. Ethernet is differential. It's CMNR. It rejects common mode noise. Why do you think they call it Common Mode Noise Rejection?

 

Can you provide any relevant links to packet noise?

 

Can you provide any relevant links to transformer coupling noise leakage and audio reproduction?

 

Bottom line is I don't believe the items you are trotting out are making it into the audio stream of a correctly engineered system. The fundamentals are easy and affordable.

 

Scew Crosstalk, Jitter, Race are all timing issues of various sorts. Again once data is in buffer it doesn't matter.

 

You are thinking I don't get it. You need to reorient to the fact: I don't care. Because timing issues on Ethernet don't affect playback outside of buffer underun. Buffers provide extraction and insulation from down stream issues. That's why they are called buffers.

 

 

BTW, all that's being said by me is that these things need to be considered as part of your evaluation of how Ethernet cables may introduce SQ issues in a connected audio system - I don't know if this actually happens in 99% of systems or at all but they are issues that need to be considered, as Jud said.

 

Your knowledge, judging by your posts, is seemingly unaware of these possibilities & it's just being pointed out to you

 

I'm aware that there is a collective here that read some technical articles without understanding the actual impacts.

 

I'm willing to show up at Axpona and demonstrate a commodity driven approach that can be achieved with plebeian consumer networking equipment all over copper interconnects.

[Paul R]

I know what these items are and I am saying you are correlating this to audibility. Ethernet is differential. It's CMNR. It rejects common mode noise. Why do you think they call it Common Mode Noise Rejection?

 

Can you provide any relevant links to packet noise?

 

Can you provide any relevant links to transformer coupling noise leakage and audio reproduction?

 

Bottom line is I don't believe the items you are trotting out are making it into the audio stream of a correctly engineered system. The fundamentals are easy and affordable.

 

Scew Crosstalk, Jitter, Race are all timing issues of various sorts. Again once data is in buffer it doesn't matter.

 

You are thinking I don't get it. You need to reorient to the fact: I don't care. Because timing issues on Ethernet don't affect playback outside of buffer underun. Buffers provide extraction and insulation from down stream issues. That's why they are called buffers.

 

 

 

 

I'm aware that there is a collective here that read some technical articles without understanding the actual impacts.

 

I'm willing to show up at Axpona and demonstrate a commodity driven approach that can be achieved with plebeian consumer networking equipment all over copper interconnects.

 

 

There is no collective mind here, the Borg are not on their way to the Rocky Mountain Audio Faire.

 

But remember, anyone can read a paper outside their speciality and come away with a pretty good understanding of the subject.

 

They won't make all the right conclusions, nor be aware of all the subtle issues, but they will have enough of an idea to ask questions.

 

Most people here are not network, audio, software, electrical, database, optical, voice transmission, radio, speaker, mathematical, or psychoacoustic experts. And an expert in one field often tries to carry over their expertise to another field, where it may or, more probably, may not be a perfect fit.

 

Hell, I know I have been guilty of that myself, and I consciously try to guard against it!

[plissken]

Here's a measurement of 8KHz USB packet noise for all objectivists - obviously not Ethernet packet noise

[ATTACH=CONFIG]19957[/ATTACH]

 

Then why post it? Is there anything showing Ethernet packet noise on a USB DAC?

 

Can someone please post some Ethernet Packet noise?

[plissken]

There is no collective mind here, the Borg are not on their way to the Rocky Mountain Audio Faire.

 

But remember, anyone can read a paper outside their speciality and come away with a pretty good understanding of the subject.

 

Only speaking for myself I have seen too many people read a white paper and come away with a gross misinterpretation that actually did them more harm than good.

 

There is a really good example at Whats best forum where a member there asked about Ethernet Jitter being stored in a file on HD.

 

He read a paper and didn't realize that the paper was referring to ether RLL or MFF endoding algorithms used on a hard drive.

 

I think this is the link: Does a file with jitter keep the jitter when saved to a hard drive?

 

The issue is that despite others telling him differently he, for several pages, dug into a position he wanted to be in.

 

I've seen this at other sites also.

 

Like here on the issue of packet loss.

 

1. Why is it being constantly paraded in this thread? I can only think the person doesn't realize how little packet drop is an issue in a home LAN environment. CRC32 will only miss 1 in 4 billion bits.

 

2. Jitter/Interpair Skew/Crosstalk etc. These are issues for any structured electrical cabling and some of it even effects optical. But they are well engineered for and buffering takes care of this for the audio reproduction side.

 

I just haven't seen any direct evidence in support. No scope, no mic, just conjecture. I'm all for a data driven approach.

[plissken]

It's interesting that you appear to be talking about the computer (sending) side of the system rather than the receiving (DAC) side. Why would having overhead left on a Celeron tell us very much about the electrical activity of an Ethernet receiver chip on a board in another piece of equipment?

 

You mean that same receiver that is there for Copper and Optical based NICS?

[plissken]

There is a Siemens white paper out there discussing differential Ethernet. They touch on two specific items: 50/60 Hz noise rejection is almost universal for differential cabling of all sorts and in regards to Ethernet their contention is in a properly installed system they state noise IMMUNITY up to 30Mz. I do understand this is for external noise.

 

I'll try to find that link.

[devs]

It's so funny to see people using their knowledge learned in school and/or their CCNA/MCSE level professional courses to try to debunk the phenomena we audiophiles perceive.

 

I'm an audiophile, also hold a degree in EE but am not a practicing EE. In my day job I'm a senior networking/network security specialist (working for the bigger companies in the banking/insurance sector) so I do know a bit more than 'the basics' of both electronics and multiple IT related subjects but I also know that with just that knowledge I hold very little useful knowledge to explain the not always subtle things I've heard and experienced since I started experimenting with the things people on this and other similar websites write about. I recognize it when other people (like Plissken here) are using that same type of knowledge to debunk things.

 

Yes, people on these forums gave the craziest explanations using their own frames of reference and knowledge (like anyone does) that often don't make any sense or are just plain wrong. It however doesn't mean they're wrong about what they're perceiving.

 

Personally I've stopped wanting or trying to explain it all. I do however remain very curious as to the why's and hows so I love reading the stuff a man like John Swenson (an actual practicing engineer who's thinking out of the box) writes. He is one of the first to admit he can't always explain with certainty what's going on yet did come up with a device (USB Regen) I would like to recommend to the closed-minded sceptics as it is a great example to show how little they actually know and how silly they look in denying it all.

 

I really feel sorry for people that can only yell 'bits are bits' but they probably feel just as sorry for me being a, what they call, "believer".

 

EVERYTHING YOU KNOW IS WRONG

[bluesman]

I'm aware that there is a collective here that read some technical articles without understanding the actual impacts

What part of "hypothesis" don't you understand? No one except you and your supporters has said anything about actual impact. Most of us are saying that we believe that one or more of the phenomena being discussed might theoretically affect sound quality, and several possible reasons have been expressed. I don't know if any is important and neither does anyone else without study that hasn't been done. But if an Ethernet cable can possibly be worth $1k+, there has to be some demonstrable benefit.

 

I don't know anything about you at all - you could be a Stanford PhD and the smartest guy who ever put plug into jack. But you've turned a simple thread in which people expressed their thoughts on whether, how & why an optimized ethernet cable could possibly affect SQ & be worth a premium price into a vituperative, haranguing monologue.

 

And whether you believe it or not, packet loss does occur in lowly home LANs. Is it significant? It's not if the network is healthy and all components and connections are well chosen and well matched. It COULD affect sound quality if suboptimal routers and switches are connected to poorly chosen and configured servers, storage and other devices by long runs of inexpertly chosen, routed and terminated cables. I don't think it's very likely.......but it's theoretically possible.

 

No one but you has been so absolute in this thread as to dismiss all concepts but your own. The fun thing about finding out you're wrong is that you learn something new. I'm sorry you'll never experience that particular pleasure.

[Jud]

You mean that same receiver that is there for Copper and Optical based NICS?

 

Yep.

 

Let's be clear what we're talking about. Someone, perhaps you, mentioned Ethernet renderers/DACs near the top of the market. If there are any differences in something like noise from the PHY, they could very well be at a level that is entirely inaudible. Or they might be such as would differentiate the very best renderer from the second best renderer in a sufficiently fanatical designer's mind. This sort of noise would be something that would never affect data throughput in a non-defective commercial system.

 

So that's what we're talking about - minimal amounts of noise either getting into the analog side of the system through ground, or into the DAC clock and slightly worsening jitter performance. Nothing near a level that would affect data transmission.

 

By the way, regarding noise from a PHY, I believe for USB this phenomenon has in fact been measured.

[plissken]

s all concepts but your own. The fun thing about finding out you're wrong is that you learn something new. I'm sorry you'll never experience that particular pleasure.

 

I just invited anyone in this community here to Axpona next April.

 

Some of the issues like transformer inductive leakage and/or coupling you have ZERO control over. It's taped and soldered onto the PCB.

 

The likes of which NAIM, Linn, NAD, Marantz, Bryston all use.

 

Packet loss is easy to measure and there are tools out there to measure this with. Packet loss means packet retransmit. You are making a red herring out of this stuff.

 

The concepts presented are dismissed because you don't actually understand what you are arguing for.

 

Packet loss on a home network is a non issue in a properly setup network. Packet loss doesn't present itself in altered audio, it presents itself in skipped audio.

 

A transceiver chip is going to be there regardless of Copper, Optical, Wireless. Regardless of the fact that they are designed to run 100% saturated because it's burst in nature. Regardless of the fact that even 1.411Mbit / second audio is only ~10% of a 100Mbit Ethernet connection, ~1% of Gbit, ~0.1% of 10Gbit.

 

So that argument went out the window

 

Never mind that Jitter, Scew, Race, Edge skew, Edge slew, etc all are non issues for audio due to buffering.

 

Next we move onto ground plane noise. This is possible with ground loop like any other system.

 

EMI/RFI. Wireless and Optical can solve these. Copper based networks are easily implemented so it's not a problem.

 

Yes I think most of these issues are in your head.

 

I'm willing to meet up with you guys at a show.

[plissken]

Yep.

 

Let's be clear what we're talking about. Someone, perhaps you, mentioned Ethernet renderers/DACs near the top of the market. If there are any differences in something like noise from the PHY, they could very well be at a level that is entirely inaudible. Or they might be such as would differentiate the very best renderer from the second best renderer

 

Or it could be any host of other numerous issues and design choices. How do you know if you perceived a difference what that difference is associated to design wise?

 

So we do agree that my bringing up high end Network Attached DACs/Pre's Whatever has some people thinking about the fact that manufacturers of impeccable pedigree indeed use copper based networking connectivity. I mean for the price they certainly could offer SC fiber Ethernet as a base or add on offering. But they don't. Why is that?

 

 

So that's what we're talking about - minimal amounts of noise either getting into the analog side of the system through ground, or into the DAC clock and slightly worsening jitter performance. Nothing near a level that would affect data transmission.

 

I just saw a graphic with measurement of the DAC being affected by USB packet timing of some sort (I wish for the context of that graph).

 

So we can agree it's measurable. Then show me the measurement of Ethernet Packet noise.

 

Is this noise mere conjecture or do you have a real example? I'm simply not interested in theory. It's just mental masturbation at that point.

 

 

By the way, regarding noise from a PHY, I believe for USB this phenomenon has in fact been measured.

 

So is this a concession to the point I previously made about packet noise and Ethernet? USB and Ethernet don't have anything to do with each other. So, respectfully, why bring up apples vs oranges?