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

[plissken]

 

EVERYTHING YOU KNOW IS WRONG

 

Feel free to make an objective, factually based, counter point then instead of a rant. Glad to see other networking professionals here with decades of experience.

[Jud]

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

 

If you mentioned buying the drinks I bet you'd get a helluva turnout.

 

Never mind that Jitter, Scew, Race, Edge skew, Edge slew, etc all are none 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.

 

 

At least we're down to "most of."

 

Just wanted to mention that there are several recognized mechanisms, some known for decades, whereby jitter may occur in a buffered system. (For one of the early ones, if you're an AES member, which I'm not, there's the Meitner-Gendron paper on logic-induced modulation.)

[plissken]

If you mentioned buying the drinks I bet you'd get a helluva turnout.

 

 

 

At least we're down to "most of."

 

Just wanted to mention that there are several recognized mechanisms, some known for decades, whereby jitter may occur in a buffered system. (For one of the early ones, if you're an AES member, which I'm not, there's the Meitner-Gendron paper on logic-induced modulation.)

 

Sure, let's plan to get together and I'll host.

 

I can probably get the paper if you can provide a link. Please understand there are all sorts of buffers. Data and Electrical are two different things but I would like to read the paper.

 

I never maintained all where in someones head...

[plissken]

Is this the paper:

 

Meitner LIM detector

[jriver]

If you mentioned buying the drinks I bet you'd get a helluva turnout.

I'll buy.

[pooger]

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.

....

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

 

+1.

 

It's back to the most basic subjectivist / objectivist argument, one I've been tired of since the tube-transistor transition in the 50s. The pattern runs pretty similar: a change in technology; measurements of known distortions are taken and shown to be much less, and lauded—yet, to some, there is more distortion. Finally, new distortions are "discovered", along with a means of measuring them, and most (but amazingly, not all) of the early deniers will accept the problems associated with the new technology. Audio is pretty subtle; at some point, all of the possible temporal, dynamic, frequency, etc. based elements will all be understood enough so that they can indeed be measured and objectified, and this argument will fade into history. (I doubt it though...)

[bluesman]

I'm simply not interested in theory. It's just mental masturbation at that point.

Perhaps the associated release of neurotransmitters explains our mellow vs your harsh. Or (and this is just a theory, from which you'll get neither inspiration nor amusement) it may actually be consensual relations between knowledge and fantasy, successful consummation of which results in conception of original ideas.

 

Eliminating theory as a source of discovery leaves only observation. Many of the things we value most would have remained unknown had someone not postulated and then proved their existence. (A reply of "Name one!" will look foolish and disingenuous.)

[mmerrill99]

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?

The problem is you deal in black & white definitions which unfortunately don't take account of the limitations of real world engineering. You use definitions but don't understand the real world aspects - how much CM noise rejection does Ethernet provide.

 

Can you provide any relevant links to packet noise?

I showed measurement of packet noise for USB by Archimago, the objectivist's friend. Any packetised system has such protocol noise - USB shows up at 8KHz but Ethernet, being bursty, will have packet noise associated with these burts.

 

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

Again do you deny transformer capacitive leakage? If noise crosses the transformer barrier then your claim of "galvanic isolation" has got holes in it. You draw your own conclusions about it's relevance to audio - I'm just laying out the hole sin your argument

 

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.

You make these statements without any appreciation of the real engineering issues

 

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

That's what I was asking you when I posted "do you think Ethernet stops when data is being read from the buffer" which you incorrectly interpreted as I was asking you if Ethernet was a real-time system, doh! Point is, if Ethernet is active while data that is already in the buffer is being read & processed by a DAC, then these noise issues could be effecting this processing - this noise is being generated by other Ethernet aspects that are happening concurrently with audio data being processed out of the buffer.

 

As I said - think in system-wide terms, not in linear, black & white terms & you may begin to understand some of the complexity.

 

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.

It's not that I "think" you don't get it - you demonstrate with every post that you don't get it & furthermore, contrary to your claim that you are willing to learn, you demonstrate the opposite

 

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

Again, you are demonstrating that you don't understand the actual implications - this can only happen when you think & not just blindly accept definitions like "galvanic isolation" "buffer isolation", etc. that you read in technical papers.

 

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.

Enjoy yourself at Axpona

[Tony Lauck]

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.

 

An "experiment" to prove a point, particularly where a monetary reward is attached, is not an experiment; it is a demo. Demos can easily be rigged and many are. (Applies to any field where technology is being sold, not just audio equipment.) This is even more likely where BS statistics are involved.

 

Fortunately, in the case of your offer no "Great" magicians (professional con-men/entertainers) are involved. The $500 is a trivial amount, probably less than travel expenses for many who might attend. No million dollar challenge here.

[plissken]

Eliminating theory as a source of discovery leaves only observation. Many of the things we value most would have remained unknown had someone not postulated and then proved their existence. (A reply of "Name one!" will look foolish and disingenuous.)

 

Actually I'm asking members here for a get together at Axpona and TEST the theory. Theories are either proved or disproved or supported or unsupported. That's why they are theories.

 

I guess the singular item I am having the most issue with is noise generated by the receiving PHY. Generated and passed onto and through the DAC.

 

I am asking your forbearance in fleshing this out for me so I can know that what I currently understand to be meant indeed is.

 

Because if it is I have a super simple test of the theory being put forward.

 

So I guess JRiver and Myself are hosting a GTG @ Axpona.

[plissken]

The problem is you deal in black & white definitions which unfortunately don't take account of the limitations of real world engineering. You use definitions but don't understand the real world aspects - how much CM noise rejection does Ethernet provide.

 

According to a Siemens paper Immunity up to 30Mhz. For 50/60 Hz all of it.

 

I showed measurement of packet noise for USB by Archimago, the objectivist's friend. Any packetised system has such protocol noise - USB shows up at 8KHz but Ethernet, being bursty, will have packet noise associated with these burts.

 

You have some balls to say I don't get it and then try to paint Ethernet packet data with a USB brush.

 

YOU made a claim. Substantiate it.

 

 

Again do you deny transformer capacitive leakage? If noise crosses the transformer barrier then your claim of "galvanic isolation" has got holes in it. You draw your own conclusions about it's relevance to audio - I'm just laying out the hole sin your argument

 

It's an issue that is not a problem with Ethernet. Galvanic isolation is the solution to this. What don't you understand about what problem (stray current leakage) that Galvanic isolation is fixing. It's WHY Ethernet PHY should be Galvanically isolated.

 

The entire reason for this in the Ethernet spec is to make difference in ground between runs a non-issue.

 

That's what I was asking you when I posted "do you think Ethernet stops when data is being read from the buffer" which you incorrectly interpreted as I was asking you if Ethernet was a real-time system, doh! Point is, if Ethernet is active while data that is already in the buffer is being read & processed by a DAC, then these noise issues could be effecting this processing - this noise is being generated by other Ethernet aspects that are happening concurrently with audio data being processed out of the buffer.

 

Great then you are stating the the noise is there when the Ethernet cable is plugged and joining two devices.

 

I will setup a rig where music can be played uninterrupted and you can indicate when the Ethernet cable is plugged or not plugged in.

 

Finally got one of you to actually and fully articulated SOMETHING in this thread.

 

It's not that I "think" you don't get it - you demonstrate with every post that you don't get it & furthermore, contrary to your claim that you are willing to learn, you demonstrate the opposite

 

I get it. Which is why I'm guaranteed no matter what venue I show up you won't ;-) Look I understand talk is one thing. Walk is entirely another.

 

Enjoy yourself at Axpona

 

I intend to.

[Allan F]

Anyone else find that much of this and other recent threads are like playing one of these over and over again? Just asking...

[bluesman]

Anyone else find that much of this and other recent threads are like playing one of these over and over again? Just asking...

[ATTACH=CONFIG]19960[/ATTACH]

Wow, Allan - you're gonna need some serious processing to rip that one into a listenable file..........

[mmerrill99]

According to a Siemens paper Immunity up to 30Mhz. For 50/60 Hz all of it.

Wow, so there's no noise issue to worry about over 30MHz!! That's an interesting blind spot you have

 

You have some balls to say I don't get it and then try to paint Ethernet packet data with a USB brush.

I showed you a physical measurement of 8KHz noise spike resulting from USB packet timing. It's not my problem if you don't understand the implications for all packetised protocols - it's your limitation. BTW, the 8KHz noise was not completely attenuated by using an optical Corning USB cable - why do you think that might be? The link is here

 

YOU made a claim. Substantiate it.

Rubbish. I gave you an explanation for various ways in which noise intrusion (leakage) might happen (not current leakage) - now you want to exaggerate this into a claim - another well known forum debating strawman tactic

 

It's an issue that is not a problem with Ethernet. Galvanic isolation is the solution to this. What don't you understand about what problem (stray current leakage) that Galvanic isolation is fixing. It's WHY Ethernet PHY should be Galvanically isolated.

 

The entire reason for this in the Ethernet spec is to make difference in ground between runs a non-issue.

I showed you the holes in your argument but keep repeating yourself & you may convince someone

 

Great then you are stating the the noise is there when the Ethernet cable is plugged and joining two devices.

Again, you are showing your failure to comprehend - I'm saying that when there is data communication on the Ethernet cable concurrent with other data being read from the buffer, then noise intrusion could be an issue.

 

I will setup a rig where music can be played uninterrupted and you can indicate when the Ethernet cable is plugged or not plugged in.

 

Finally got one of you to actually and fully articulated SOMETHING in this thread.

 

I get it. Which is why I'm guaranteed no matter what venue I show up you won't ;-) Look I understand talk is one thing. Walk is entirely another.

 

I intend to.

Great, I wish you all the best but you are locked in your own logic box!!

[plissken]

Wow, so there's no noise issue to worry about over 30MHz!! That's an interesting blind spot you have

 

I showed you a physical measurement of 8KHz noise spike resulting from USB packet timing. It's not my problem if you don't understand the implications for all packetised protocols - it's your limitation. BTW, the 8KHz noise was not completely attenuated by using an optical Corning USB cable - why do you think that might be? The link is here

 

Wow. Just Wow. USB to DAC is REALTIME. Ethernet is Not. You fail to realize the difference between RT and NRT operations.

 

I don't know about anyone else here but worrying about noise rejection at 30 MILLION Cycles per second for the intents of audio reproduction is just an astounding display of ignorance.

[Tony Lauck]

Actually I'm asking members here for a get together at Axpona and TEST the theory. Theories are either proved or disproved or supported or unsupported. That's why they are theories.

 

I guess the singular item I am having the most issue with is noise generated by the receiving PHY. Generated and passed onto and through the DAC.

 

I am asking your forbearance in fleshing this out for me so I can know that what I currently understand to be meant indeed is.

 

Because if it is I have a super simple test of the theory being put forward.

 

So I guess JRiver and Myself are hosting a GTG @ Axpona.

 

The timing of the packet noise depends on the protocol being used above the base interconnect mechanism. However, given that it is a packet based system there will be bursts of activity corresponding to the packets and the inter-packet gaps. In the case of USB audio it is easy to detect this periodic activity in the analog output of a DAC because it will show up in a spectrum at certain frequencies (e.g. 8 kHz). The measurement situation may be different with Ethernet, because there are various high level protocols which may or may not be periodic, making it more difficult to do coherent averaging of the analog results. It does not mean that this packet noise is not present if a simple means is used to detect it.

 

If you want to get to the cause of the packet noise, you need detailed instrumentation of the hardware and software. This requires a hardware lab. It is not something that an be done in a trade show environment.

[plissken]

I showed you the holes in your argument but keep repeating yourself & you may convince someone

 

I'm convinced that it doesn't matter if I show at Axpona, Cap AudioFest, RMAF. Because no one here really believes in their interpretations to actually show up and try for $500.

 

$500 to anyone's $100 says in a Server/Switch/Client setup you won't be able to tell when the Ethernet cable is plugged in or not while music is playing.

 

Since that is the argument being made here.

[mmerrill99]

Wow. Just Wow. USB to DAC is REALTIME. Ethernet is Not. You fail to realize the difference between RT and NRT operations.

 

I don't know about anyone else here but worrying about noise rejection at 30 MILLION Cycles per second for the intents of audio reproduction is just an astounding display of ignorance.

I won't waste my time with this any more - your display of confused linear thinking is just too big a gap to attempt to bridge when it's allied with your refusal to let any new ideas into your tightly sealed logic box

[plissken]

The timing of the packet noise depends on the protocol being used above the base interconnect mechanism. However, given that it is a packet based system there will be bursts of activity corresponding to the packets and the inter-packet gaps. In the case of USB audio it is easy to detect this periodic activity in the analog output of a DAC because it will show up in a spectrum at certain frequencies (e.g. 8 kHz). The measurement situation may be different with Ethernet, because there are various high level protocols which may or may not be periodic, making it more difficult to do coherent averaging of the analog results. It does not mean that this packet noise is not present if a simple means is used to detect it.

 

If you want to get to the cause of the packet noise, you need detailed instrumentation of the hardware and software. This requires a hardware lab. It is not something that an be done in a trade show environment.

 

For all the talk about the expertise here you are still failing to realize there is a firewall between the Ethernet packet and the DAC.

 

USB is a straight connection to the clocking buffer on a DAC.

 

The DAC doesn't know if it's being fed from local storage or over a network.

 

And since Archimago is being brought up. He did a test with is Transporter where he had a friend host the audio in Sweden.

 

If you want to go there the by all means:

 

Archimago's Musings: MEASUREMENTS: The Intercontinental Internet Audio Streaming Test...

[plissken]

If you want to get to the cause of the packet noise, you need detailed instrumentation of the hardware and software. This requires a hardware lab. It is not something that an be done in a trade show environment.

 

B.S. You are equating this to AUDIBILITY. This is an AUDIO website. No lab needed. Just need someone, anyone, with just a modicum of faith in what they think they know and their ears.

[Tony Lauck]

Wow. Just Wow. USB to DAC is REALTIME. Ethernet is Not. You fail to realize the difference between RT and NRT operations.

 

It's not clear that you realize the differences either. There are various components in a distributed system and there are various timing relationships between them that are required for correct operation. Accordingly, there are various definitions of "real time", depending on which system you are discussing and which application you expect it to perform.

 

There also different versions of Ethernet and these have different performance capabilities, not just with respect to bandwidth but also with respect to probability distribution of packet delivery times. That's just at the PHY and MAC layer. It gets more complicated at higher layers, especially where there is buffering and switching in the network.

[plissken]

I'm saying that when there is data communication on the Ethernet cable concurrent with other data being read from the buffer, then noise intrusion could be an issue.

 

Great, I wish you all the best but you are locked in your own logic box!!

 

At least you are publicly willing to put your misunderstanding of data buffering on public display.

[plissken]

It's not clear that you realize the differences either.

 

You do realize, well I hope you do at least, that to a USB DAC all data it fetches is 100% always local. It has zero idea if was delivered via Ethernet, RS485, local storage.

 

I'm here to tell you can not make claims of audible performance and in the next sentence do a 180 degree about face and state a lab full of equipment is needed.

 

We are at the point that you either have the chops to back this up. I'm totally willing to host at GTG in Chicago and put it to the test.

[plissken]

It's not clear that you realize the differences either. There are various components in a distributed system and there are various timing relationships between them that are required for correct operation. Accordingly, there are various definitions of "real time", depending on which system you are discussing and which application you expect it to perform.

 

Realtime is like pregnant. There is no such thing as a little pregnant.

 

Ethernet isn't dependent on a time based corrector. It's a data protocol. Not an audio protocol.

[Tony Lauck]

For all the talk about the expertise here you are still failing to realize there is a firewall between the Ethernet packet and the DAC.

 

USB is a straight connection to the clocking buffer on a DAC.

 

It appears that you don't know how USB audio works in modern DACs that use asynchronous USB operation or equivalent.