Do I really need an " Audio Grade Network Switch "?

jmusica said:
I find SQ of local digital streamed from NAS (or Lumin L1, which is a proprietary NAS for Lumin streamers) generally better than internet-streamed, even from hi-res sources like Qobuz. I don't really have enough info or expertise to venture an (educated) guess as to why, but I tend to doubt it has to do with the switch- both sources go that route.
Click to expand...
It can most definitely be due to the switch, particularly if the switch is powered using a Switch-mode power supply. Also, the cheap-*ss clocks in the switch can contribute phase noise and jitter. All of which is audible.

The reason digital music file content that is resident on a streamer (e.g. an Aurender, Lumin, etc) generally sounds better than streaming from Tidal, Qobuz, etc., is because those files have to pass through a smaller number of "devices" and interfaces (cables and digital comm receivers) before it gets to the DAC. Fewer things to pass through means less inpact from phase noise, "leaky" cores in isolation transformers in the receivers, threshold jitter, high-source impedance leakage current, and other timing-impacting noise factors.

jmusica said:
I
I recently read an article on What's Best Forum where a very detailed reviewer insists he heard a difference when replacing his switch with the Netgear S8000, which is a gamer-oriented switch, and coincidentally the switch I've used for years and just replaced with a Cisco Meraki, because the Meraki has an in-built SFP port, whereas I had to use 2 converters with the Netgear. Can't say I've detected a difference.
I guess at the end of the day, if pressed my input would be spend your $ (and time) elsewhere in the audio chain; I'd think any difference would be more detectable elsewhere than a network switch.
Click to expand...

That's not true, either. The switch and the Ethernet cables can cause a notable degradation of audio quality from files sent via Ethernet from a server to a streamer/network bridge or DAC with a LAN connection (e.g. the Linn Klimax series). Also the power supplies for the music server, router and switch(es) also contribute noise components that also make an easily discernable impact on "streamed" audio quality. Then there is the impact of common-mode noise that can be introduced by Ethernet and USB cables (which is why I use Shunyata Ethernet and USB cables, because they specifically remove common-mode noise).

Read this paper by John Swenson carefully (it's pretty deep): shorturl.at/coqFP. John Swenson, who is the designer and lead engineer for the UpTone Audio EtherREGEN, IsoREGEN, Sonore OpticalModule, UltraRendu and OpticalRendu, was a professional Ethernet electrical engineer that spent his career at Broadcom and Cisco developing Ethernet-based networking technologies, so you're getting this info from the best source in the audio industry.
 
rbbert said:
I also doubt it is due to a switch, or to any particular switch
Click to expand...

That's not accurate, either. The Ethernet switch, it's cheap-*ss clocks, Ethernet receivers, power supply, and transformer cores in the receivers can all have an impact on the audio quality. You can also get high-source leakage impedance current between the RJ45 Ethernet receivers that can have an audible impact, as well.

And then, there's common-mode noise, which can...also be in the Ethernet cables. Doh! 😜
 
jmusica said:
This is the bit I have trouble connecting the dots - or in this case, bits - on. How does a series of 0s and 1s induce - or conversely, solve - jitter? May well be the case, but I sure don’t understand it. And as you’ve said, there seems little-to-no scientific/empirical proof of said.
Click to expand...

Okay....the only aspect of digital music that involves 0s and 1s that the music file is encoded in binary form (0s and 1s). The actual signal that is sent from a server to a switch to via then to a network bridge/streamer, etc. is an analog voltage in the form of a square wave. While the analog voltage is "hypotheticaly" a square wave, in reality, the shape and timing of the analog voltage square wave can be impacted by the "clock edges" and thus, can be "smeared" by phase noise, "conventional" jitter and...threshold jitter (which is induced by noise on the ground plane of the analog square wave "signal voltage" that also leads to, once again...timing errors).

So, there are LOT of places where "things" can go "wrong", can distort "clock edges" and thus impact 1) timing and 2) jitter. The impact of ALL of these are quite audible.
 
Puma Cat said:
Read this paper by John Swenson carefully (it's pretty deep): URL Shortener. John Swenson, who is the designer and lead engineer for the UpTone Audio EtherREGEN, IsoREGEN, Sonore OpticalModule, UltraRendu and OpticalRendu, was a professional Ethernet electrical engineer that spent his career at Broadcom and Cisco developing Ethernet-based networking technologies, so you're getting this info from the best source in the audio industry.
Click to expand...

As a design engineer, I would have to understand the mechanisms causing the issue. I would experiment with different components and topologies to determine what worked best. As an engineer/scientist, I would rely on measurements in addition to my ears to optimize the design. Yet no device or cable manufacturer has chosen to share any objective evidence that their products actually reduce the impact of the distortion mechanisms they have so eloquently described.
 
W9TR said:
As a design engineer, I would have to understand the mechanisms causing the issue. I would experiment with different components and topologies to determine what worked best. As an engineer/scientist, I would rely on measurements in addition to my ears to optimize the design. Yet no device or cable manufacturer has chosen to share any objective evidence that their products actually reduce the impact of the distortion mechanisms they have so eloquently described.
Click to expand...

Hey Tom, my suggestion is to read John's white paper linked above thoroughly. Admittedly it's pretty deep, but you have the credentials and domain expertise to understand what John is talking about. Cheers, mate.
 
Puma Cat said:
The actual signal that is sent from a server to a switch to via then to a network bridge/streamer, etc. is an analog voltage in the form of a square wave
Click to expand...

Thanks for all the additional info, it's helpful. Now that you've said it, I vaguely remember this from some network engineering course, and it starts to make more sense. (and helps explain why streaming from a local network device sounds better than an internet stream, and why Lumin allows you to connect their NAS directly via ethernet to the streamer)
 
jmusica said:
Thanks for all the additional info, it's helpful. Now that you've said it, I vaguely remember this from some network engineering course, and it starts to make more sense. (and helps explain why streaming from a local network device sounds better than an internet stream, and why Lumin allows you to connect their NAS directly via ethernet to the streamer)
Click to expand...

Yup. Lumin's got it goin' on...they "get it".

Check out that white paper by John Swenson. It explains pretty much everything.
 
Stephen,
I’ve read it and understand it. John has done an excellent job describing the distortion mechanisms involved, and how they may impact a digital playback chain. It’s a fine piece of work. I have made changes to my system to reduce the kind of errors he discusses in the white paper. I’ve noticed sonic improvements that are substantive.

What I see here is a missed opportunity. I’m a member of the Audio Engineering Society, and there have been dramatic improvements in the capability of test equipment used to measure the performance of digital systems. AES17-2020 describes test methodologies that, with the right gear, will allow measurement of jitter spectra orders of magnitude below the noise and distortion floor of the equipment being measured. This is not a case of ‘you can hear what you can’t measure’.

So these devices continue to be considered audiophile nonsense to some, even though they may have merit.

That is the missed opportunity.
 
W9TR said:
Stephen,
I’ve read it and understand it. John has done an excellent job describing the distortion mechanisms involved, and how they may impact a digital playback chain. It’s a fine piece of work. I have made changes to my system to reduce the kind of errors he discusses in the white paper. I’ve noticed sonic improvements that are substantive.

What I see here is a missed opportunity. I’m a member of the Audio Engineering Society, and there have been dramatic improvements in the capability of test equipment used to measure the performance of digital systems. AES17-2020 describes test methodologies that, with the right gear, will allow measurement of jitter spectra orders of magnitude below the noise and distortion floor of the equipment being measured. This is not a case of ‘you can hear what you can’t measure’.

So these devices continue to be considered audiophile nonsense to some, even though they may have merit.

That is the missed opportunity.
Click to expand...

Got it. Thanks, Tom!
 
Ok, still processing (no pun intended). Help me with this part:

The 0s and 1s are sent as voltages, in the form of an ethernet packet (frame). The packet is expected to take a very specific form - header, source, destination, data, frame check etc. So are you saying that in the data payload of the ethernet packet, the 0s and 1s can basically be "corrupted" by noise etc? Wouldn't that lead to the packet being malformed and rejected and show up as errors and retries in the switch? Or is it more subtle than that and the data payload is basically just not properly representing the original 0s and 1s contained in the music file? (in which case it seems like a miracle that internet-streamed music gets to the endpoint sounding like music at all, with all the network hops/equipment and cabling and datacenter environments etc it has to traverse before it even enters your home)
 
jmusica said:
Ok, still processing (no pun intended). Help me with this part:

The 0s and 1s are sent as voltages, in the form of an ethernet packet (frame). The packet is expected to take a very specific form - header, source, destination, data, frame check etc. So are you saying that in the data payload of the ethernet packet, the 0s and 1s can basically be "corrupted" by noise etc? Wouldn't that lead to the packet being malformed and rejected and show up as errors and retries in the switch? Or is it more subtle than that and the data payload is basically just not properly representing the original 0s and 1s contained in the music file? (in which case it seems like a miracle that internet-streamed music gets to the endpoint sounding like music at all, with all the network hops/equipment and cabling and datacenter environments etc it has to traverse before it even enters your home)
Click to expand...

I’m saying the opposite. The data will get there uncorrupted. But along with that data comes a bunch of noise - from power supplies, from the data itself, from switches, cables, and other network gear. This noise appears on the grounds of audio gear connected to your network, and this noise then corrupt how your DAC interprets the timing of the data - not the data itself. That creates jitter, which we know to be audible. That’s the mechanism.
 
It seems that one issue is people do not understand how digital data is transmitted. It is transmitted as an analog signal that is then turned into digital in the receiving device. Because the analog signal can be changed, the point where a 0 or 1 is determined can be slightly different from what was originally transmitted, which leads to jitter.
 
W9TR said:
I’m saying the opposite. The data will get there uncorrupted. But along with that data comes a bunch of noise - from power supplies, from the data itself, from switches, cables, and other network gear. This noise appears on the grounds of audio gear connected to your network, and this noise then corrupt how your DAC interprets the timing of the data - not the data itself. That creates jitter, which we know to be audible. That’s the mechanism.
Click to expand...

Yes, and with respect to timing errors, our brains are sensitive to these timing errors in the picosecond range, which is why we need femtoclocks for our audio-grade digital devices.
 
BlueFox said:
It seems that one issue is people do not understand how digital data is transmitted. It is transmitted as an analog signal that is then turned into digital in the receiving device. Because the analog signal can be changed, the point where a 0 or 1 is determined can be slightly different from what was originally transmitted
Click to expand...

Definitely the part that I'd forgotten. Even when I learned it, was sort of like grammar. "Meh, rules, why would I ever need to know that, I just need to know how to check for errors on a switch port and have some idea what things could cause it :)". Live and learn, as they say.

This has all been an interesting and useful (re)education. For me at least.

But now, got me looking at audiophile ethernet switches dammit.
 
jmusica said:
Definitely the part that I'd forgotten. Even when I learned it, was sort of like grammar. "Meh, rules, why would I ever need to know that, I just need to know how to check for errors on a switch port and have some idea what things could cause it :)". Live and learn, as they say.

This has all been an interesting and useful (re)education. For me at least.

But now, got me looking at audiophile ethernet switches dammit.
Click to expand...

Just get an EtherREGEN from UpTone Audio. Easy. Only $640. Has UpTone's proprietary ADIM and a really good clock, the Crystek CCHD-575 oscillator.

EtherREGEN – UpTone Audio
 
Puma Cat said:
Just get an EtherREGEN from UpTone Audio. Easy. Only $640. Has UpTone's proprietary ADIM and a really good clock, the Crystek CCHD-575 oscillator.

EtherREGEN – UpTone Audio
Click to expand...

Mehbe. Would you say this, or the SoTM sNH-10G and just replace my current switch?

With the REGEN I could still go fiber out on the in-built SFP port, to the X1, correct?

Update: I see, I would do it this way: "For the few people who have an endpoint with optical input, one can “turn around” the EtherREGEN and feed that DAC-connected endpoint from the optical cage, while connecting the lone ‘B’-side port to the network. Thus ‘B’ >’A’. "

Pretty cool. I used to do this for USB, and the results were clear to me, so in concept (and reputation), this makes sense to me now also. Guess I just had to stitch the pieces together.
 
jmusica said:
Mehbe. Would you say this, or the SoTM sNH-10G and just replace my current switch?

With the REGEN I could still go fiber out on the in-built SFP port, to the X1, correct?

Update: I see, I would do it this way: "For the few people who have an endpoint with optical input, one can “turn around” the EtherREGEN and feed that DAC-connected endpoint from the optical cage, while connecting the lone ‘B’-side port to the network. Thus ‘B’ >’A’. "

Pretty cool. I used to do this for USB, and the results were clear to me, so in concept (and reputation), this makes sense to me now also. Guess I just had to stitch the pieces together.
Click to expand...

Yep, J, you've got it, buddy. The EtherREGEN can be used "either way", i.e., in either orientation. So, if you've got a Lumin, you can go into B-side with copper Ethernet, and then run fiber out of A-side directly to your Lumin. The SOtM doesn't have an SFP cage...
 
jmusica said:
With the REGEN I could still go fiber out on the in-built SFP port, to the X1, correct?
Click to expand...

Yes.

Regardless of fiber or copper Ethernet, the recommended connection is this:

WiFi router (or switch) -> side B - EtherREGEN - side A -> Lumin T2 / X1 / P1 / U1 (MINI) / M1

WiFi router (or switch) -> side A - EtherREGEN - side B -> Lumin S1 / A1 / T1 / D1

Make sure you use unshielded CAT-6 network cable with EtherREGEN.
 
You must log in or register to reply here.
Back
Top