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

[plissken]

You fail in your ability to think in system terms - Ethernet data delivery is not some isolated event that occurs completely isolated from the rest of the system. Ethernet receiver chips in audio device have an intimate connection with the downstream sensitive analogue systems such as DAC clock & DAC output stages via the ground plane.

 

No, Ethernet is galvonically isolated. Motherboards are heavily grounded, DAC's are designed with differential and galvonically isolated inputs to reject noise.

 

Also you said "Do you think communication over the ethernet link stops while the buffer is being emptied"

 

That leads me to believe you do not know what you are talking about. So what do I do in a handful of minutes. I prove to you what I already knew with a quick video.

 

Communication over a link does indeed stop. Now that you can't make your time domain based argument anymore you are now going to move onto the 'Ground plane pollution' hyperbole.

[plissken]

What does this have to do with jitter and latency in computer audio? Samba is a file access & transfer protocol at the application level. Multichannel facilitates load balancing by enabling multiple connections, eg in a data center. If there's more, please explain......nicely. I'd like to learn whatever there is to learn.

 

You have to consider that what you quoted from me is in relation to post 159.

 

And again Jitter on Ethernet has zero affect on a DAC. They are not related, coupled, combined, inter-twinned other than a loss of connection that exceeds the buffer.

 

Jitter as of this post is mentioned 35 times on this page alone as it relates to Ethernet and Audio.

 

It's actually amazing that a site that is dedicated to computer is having this happen.

[mmerrill99]

But they do. Or they wouldn't argue that Jitter on and Ethernet cable is going to affect sound quality on a buffered device. Whether it be a PC/Mac/Linux box or Network attached DAC.

 

Your own post #159 just stipulated that it's real time. You said "Do you think communication over the ethernet link stops while the buffer is being emptied or what exactly"

No, it didn't stipulate that - that your pidgeon-holing of others posts - I was talking about the inherent noise of Etherent comms while the audio was being played from the data in the buffer. Please take a minute to think about posts before replying - I know that posting can get hectic & seem like you are in a game of speed-chess - but you aren't

 

I didn't state "I think" or "what exactly". I know, not think. Watch the video.

 

Yes communication over the Ethernet link stopped. For crying out loud...

Huh?

[plissken]

No, it didn't stipulate that - that your pidgeon-holing of others posts - I was talking about the inherent noise of Etherent comms while the audio was being played from the data in the buffer. Please take a minute to think about posts before replying - I know that posting can get hectic & seem like you are in a game of speed-chess - but you aren't

 

 

 

I have to take your statement at face (typed) value. If having an Ethernet cable plugged in is enough to raise the noise floor or introduce RFI then you have something broken with your setup.

 

NAIM, NAD, LINN, Bryston, Cambridge, Lumin, Sim Audio, Sony, Oppo, AURALiC, Marantz, Krell all make wired Ethernet streamers.

[plissken]

 

Huh?

 

Did you watch the video? 'Comms' stopped. As a matter of fact at the end I turned on AirPlane mode for the last ~20 seconds.

[Jud]

plissken (Snake? ) -

 

Speaking of listening when folks are saying stuff it's possible to learn from:

 

What at least some folks are suggesting is looking for jitter/noise from secondary effects. We know the timing of the transmissions doesn't "contain" jitter. Just wondering if any problems with timing or noise make the receiving circuitry work harder and may thus put noise into the DAC clock causing jitter, or send noise through ground into the analog side of the DAC.... Those are the sorts of things we're wondering about.

[mmerrill99]

No, Ethernet is galvonically isolated. Motherboards are heavily grounded, DAC's are designed with differential and galvonically isolated inputs to reject noise.

 

Also you said "Do you think communication over the ethernet link stops while the buffer is being emptied"

 

That leads me to believe you do not know what you are talking about. So what do I do in a handful of minutes. I prove to you what I already knew with a quick video.

 

Communication over a link does indeed stop. Now that you can't make your time domain based argument anymore you are now going to move onto the 'Ground plane pollution' hyperbole.

Again, you are not playing speed-chess- stop trying to find the checkmate move

I have not "move onto the 'Ground plane pollution' hyperbole." - it was my point all along - nothing to do with your assumption that I was saying Ethernet is realtime.

 

You fail to understand things at the electrical level (as well as the system level), it seems. Galvanic isolation in Ethernet transformers is something you should find out a bit about before using the term as you do. Transformers have capacitive leakage across their primary & secondary windings which allow certain frequencies to bridge the gap & also allows common mode noise to cross this "galvanic barrier"

 

You completely missed the point about bad signal integrity causing noise in Etherent PHY - this signal appears on the other side of the Ethernet transformer.

 

As I said, start to think in system wide terms & somewhat deeper than you are currently.

[mmerrill99]

I have to take your statement at face (typed) value. If having an Ethernet cable plugged in is enough to raise the noise floor or introduce RFI then you have something broken with your setup.

 

NAIM, NAD, LINN, Bryston, Cambridge, Lumin, Sim Audio, Sony, Oppo, AURALiC, Marantz, Krell all make wired Ethernet streamers.

 

As Tony Lauck already said "Bits should be just Bits but currently aren't" i.e it's not an exception - all CA setups are broken - some more than others

[plissken]

plissken (Snake? ) -

 

Speaking of listening when folks are saying stuff it's possible to learn from:

 

What at least some folks are suggesting is looking for jitter/noise from secondary effects. We know the timing of the transmissions doesn't "contain" jitter. Just wondering if any problems with timing or noise make the receiving circuitry work harder and may thus put noise into the DAC clock causing jitter, or send noise through ground into the analog side of the DAC.... Those are the sorts of things we're wondering about.

 

No. Again because even if there was momentary strain it's not real time. The DAC is reading the buffer from the top of the heap, Ethernet is filling the bottom of the heap.

 

At the data rate involved for full bit rate file there simply isn't enough to cause a strain.

 

Look I did 24/192 audio over 54Mbit wireless in the video I shot. On a $219 single cpu Celeron based ASUS laptop. I still have 40% CPU overhead*Edit* Headroom, not overhead*/EDIT* It's right there in the video.

 

So not only is it 24/192, on a cheap single CPU Celeron laptop, I'm also running a screen recording application writing to disk almost 720p.

[bluesman]

It's actually amazing that a site that is dedicated to computer is having this happen.

So I'll ask again: what does Samba have to do with sound quality, latency, and/or jitter? I can't think of anything, but you apparently can. Please teach me / us.

[plissken]

Again, you are not playing speed-chess- stop trying to find the checkmate move

I have not "move onto the 'Ground plane pollution' hyperbole." - it was my point all along - nothing to do with your assumption that I was saying Ethernet is realtime.

 

You fail to understand things at the electrical level (as well as the system level), it seems. Galvanic isolation in Ethernet transformers is something you should find out a bit about before using the term as you do. Transformers have capacitive leakage across their primary & secondary windings which allow certain frequencies to bridge the gap & also allows common mode noise to cross this "galvanic barrier"

 

You completely missed the point about bad signal integrity causing noise in Etherent PHY - this signal appears on the other side of the Ethernet transformer.

 

As I said, start to think in system wide terms & somewhat deeper than you are currently.

 

There is a really good T.I. white paper on EMI and RFI mitigation as it pertains to implementation of both the PHY and general infrastructure implementation.

 

That is grounding the rack, running shielded CAT5/6, singled ended vs balanced power supplies etc...

 

These are well understood engineering problems and well controlled for.

 

Go wireless or go optical but please for pete's sake be done with marching out the Jitter bogey man or with your ascertation that Ethernet is real time since you expressed credulity at me stating that Ethernet stops and starts transmission as playback is happening.

 

Why isn't NAIM, Linn, Bryston, Lumin, Sim Audio, Oppo, Marantz etc... introducing Network Attached Players with SC fiber as either a default or with a PCIe slot or some such to add it?

[plissken]

So I'll ask again: what does Samba have to do with sound quality, latency, and/or jitter? I can't think of anything, but you apparently can. Please teach me / us.

 

I can't teach you to read in context even though I pointed out to you that I was responding to a tangential post 159.

 

Now I can tie it into post 181 if you like...

[bluesman]

Ethernet is filling the bottom of the heap.

Ethernet has two termini. But what goes in doesn't necessarily come out exactly as it went in. And some packets don't come out in time to jump back in line, so they're functionally lost. It doesn't matter where in the transfer the data stream is corrupted. "Bottom of the heap"? How does this matter?

[plissken]

Ethernet has two termini. But what goes in doesn't necessarily come out exactly as it went in. And some packets don't come out in time to jump back in line, so they're functionally lost.

 

How in the would would you know this is happening?

 

Packets lost in TCP/IP don't get lost, they get retransmitted. CRC32 will even only miss 1 bit in 4 billion.

 

You're assuming loss is happening in a Server/Switch/Client network. You might as well move back to all analog formats.

 

And most assuredly what goes in DOES come out.

 

How about this. I will post a file with an MD5 hash. Everyone that would like to participate can download the file, run the hash check utility against it.

 

We could also use the windows command line utility: COMP.

 

Feel free to download the file, copy the file, as many times as you wish and run COMP or calculate the HASH.

 

Let me know when you finally get a different HASH after a successful download or copy.

 

I can setup an FTP server pretty quick.

[bluesman]

I can't teach you to read in context even though I pointed out to you that I was responding to a tangential post 159.

 

Now I can tie it into post 181 if you like...

This is starting to feel like a Cellini movie.

[plissken]

This is starting to feel like a Cellini movie.

 

Coming from the guy that thinks packets entering an Ethernet cable don't come out the other end the same.

[jriver]

No. Again because even if there was momentary strain it's not real time. The DAC is reading the buffer from the top of the heap, Ethernet is filling the bottom of the heap.

 

At the data rate involved for full bit rate file there simply isn't enough to cause a strain.

 

Look I did 24/192 audio over 54Mbit wireless in the video I shot. On a $219 Celeron based ASUS laptop. I still have 40% CPU overhead. It's right there in the video.

 

So not only is it 24/192, on a cheap single CPU Celeron laptop, I'm also running a screen recording application writing to disk almost 720p.

 

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?

[mmerrill99]

There is a really good T.I. white paper on EMI and RFI mitigation as it pertains to implementation of both the PHY and general infrastructure implementation.

 

That is grounding the rack, running shielded CAT5/6, singled ended vs balanced power supplies etc...

 

These are well understood engineering problems and well controlled for.

Yes & what I told you about galvanic isolation, Ethernet transformers & signal integrity are well known engineering issues. They are well controlled for in the context of digital transmission i.e ensuring the system-wide noise & jitter budget stay within the accepted maximum for DIGITAL COMMUNICATION. We are in a mixed signal environment when dealing with digital audio - this noise & jitter budget maximum does not unfortunately apply to this analogue side of the environment.

 

Go wireless or go optical but please for pete's sake be done with marching out the Jitter bogey man or with your ascertation that Ethernet is real time since you expressed credulity at me stating that Ethernet stops and starts transmission as playback is happening.

Give up the strawman argument - I didn't assert any such thing!! try to understand the points being made & you will demonstrate the claim you made of being able to learn from others.

 

Why isn't NAIM, Linn, Bryston, Lumin, Sim Audio, Oppo, Marantz etc... introducing Network Attached Players with SC fiber as either a default or with a PCIe slot or some such to add it?

?

[plissken]

Yes & what I told you about galvanic isolation, Ethernet transformers & signal integrity are well known engineering issues. They are well controlled for in the context of digital transmission i.e ensuring the system-wide noise & jitter budget stay within the accepted maximum for DIGITAL COMMUNICATION. We are in a mixed signal environment when dealing with digital audio - this noise & jitter budget maximum does not unfortunately apply to this analogue side of the environment.

 

Give up the strawman argument - I didn't assert any such thing!! try to understand the points being made & you will demonstrate the claim you made of being able to learn from others.

 

?

 

Don't '?' when you know darn well what I am getting at:

 

If Ethernet is SOOOO Fraught with issues then why are there multi-thousand $$ network attached players. Players that are at the pinnacle of audio reproduction, most all plugged in with copper Ethernet cabling costing in the ~$1 / foot range or less. Gosh and Golly how does Bryston do it?

 

I'm just absolutely baffled by it.

[mmerrill99]

Don't '?' when you know darn well what I am getting at:

 

If Ethernet is SOOOO Fraught with issues then why are there multi-thousand $$ network attached players. Players that are at the pinnacle of audio reproduction, most all plugged in with copper Ethernet cabling costing in the ~$1 / foot range or less. Gosh and Golly how does Bryston do it?

 

I'm just absolutely baffled by it.

You are taking people's explanation for a possible mechanism for how an Ethernet cable MAY have an effect on the sound & exagerrating it into your phrase "If Ethernet is SOOOO Fraught with issues" - come on - it's another strawman

[bluesman]

Coming from the guy that thinks packets entering an Ethernet cable don't come out the other end the same.

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.......

[Tony Lauck]

But they do. Or they wouldn't argue that Jitter on and Ethernet cable is going to affect sound quality on a buffered device. Whether it be a PC/Mac/Linux box or Network attached DAC.

 

Your own post #159 just stipulated that it's real time. You said "Do you think communication over the ethernet link stops while the buffer is being emptied or what exactly"

 

I didn't state "I think" or "what exactly". I know, not think. Watch the video.

 

Yes communication over the Ethernet link stopped. For crying out loud...

 

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.

[YashN]

plissken (Snake? )

 

Did you know John Carpenter recently made a new album?

 

Now, he only has to make the movies to go with the tracks, they're all very cinematic.

[Jud]

No. Again because even if there was momentary strain it's not real time. The DAC is reading the buffer from the top of the heap, Ethernet is filling the bottom of the heap.

 

At the data rate involved for full bit rate file there simply isn't enough to cause a strain.

 

Look I did 24/192 audio over 54Mbit wireless in the video I shot. On a $219 single cpu Celeron based ASUS laptop. I still have 40% CPU overhead*Edit* Headroom, not overhead*/EDIT* It's right there in the video.

 

So not only is it 24/192, on a cheap single CPU Celeron laptop, I'm also running a screen recording application writing to disk almost 720p.

 

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.

[plissken]

You are taking people's explanation for a possible mechanism for how an Ethernet cable MAY have an effect on the sound & exagerrating it into your phrase "If Ethernet is SOOOO Fraught with issues" - come on - it's another strawman

 

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