Article: SOtM sNH-10G Network Switch Review

[incus]

Good question. Ask SOtM if they have any. They must base their designs on something, right? Not just throwing diodes at a board...

 

But I'm curious what you need to see that would make you at least entertain the possibility of an uptick in listening pleasure coming from such tech? In other words, what exactly would you be asking some theoretical device to measure? It can't just be frequency and jitter. Clearly there is more going on here. Why don't you explain to us all why different switches sound different from one another. And if you tell me they don't, then we will have to stop this discussion because it means you have not tried any of the products detailed herein.

[LowMidHigh]

42 minutes ago, incus said:

Good question. Ask SOtM if they have any. They must base their designs on something, right? Not just throwing diodes at a board...

 

But I'm curious what you need to see that would make you at least entertain the possibility of an uptick in listening pleasure coming from such tech? In other words, what exactly would you be asking some theoretical device to measure? It can't just be frequency and jitter. Clearly there is more going on here. Why don't you explain to us all why different switches sound different from one another. And if you tell me they don't, then we will have to stop this discussion because it means you have not tried any of the products detailed herein.

It can't just be frequency and jitter. Clearly there is more going on here

 

"Clearly" to whom? 

 

No need to be chasing unicorns. Reducing jitter and phase noise goes a long way to explain the difference among switches. 

[incus]

3 hours ago, LowMidHigh said:

It can't just be frequency and jitter. Clearly there is more going on here

 

"Clearly" to whom? 

 

No need to be chasing unicorns. Reducing jitter and phase noise goes a long way to explain the difference among switches. 

You are an external master-clocker, I see. So you know what this can bring. Obviously lower jitter, lower phase noise, shunting of high frequency incursions, etc. all have their impact. But I personally believe in unicorns. That there are effects inherent to certain designs that create more pleasure and the experience of musical "rightness" that aren't entirely attributable to the quantifiable data of that design. Along the lines of synergy within a given audio system. I believe, also, that one day measurements will catch up with our subjective experiences of streaming audio the way measurements can now explain our different experiences of early USB DACs. Think how far USB receiver chips and FPGAs have come in the last 5 years alone - Gordon Rankin started asking questions a while ago about the hows and whys of better sound through USB. That lead to us measuring things we never thought to measure and building things we never thought to build before. I truly believe streaming audio is at that frontier poised before an explosive exponential growth curve. Anyway...

[plissken]

46 minutes ago, incus said:

You are an external master-clocker, I see. So you know what this can bring. Obviously lower jitter, lower phase noise, shunting of high frequency incursions, etc. all have their impact.

 

I dare you to answer this one simple question:

 

What happens to all of what you posted when the Ethernet cable is pulled and the music plays on?

[thyname]

16 minutes ago, plissken said:

What happens to all of what you posted when the Ethernet cable is pulled and the music plays on?

 

‘You keep repeating the same thing over and over again, for years, in hundreds of forums and threads. Eureka!

[LowMidHigh]

25 minutes ago, plissken said:

 

I dare you to answer this one simple question:

 

What happens to all of what you posted when the Ethernet cable is pulled and the music plays on?

 

When I stream using Airplay, the music stops. 

 

In general, the internet orange light flashes repeatedly, so network traffic is ongoing. 

 

Does that help you understand? 

[plissken]

10 hours ago, LowMidHigh said:

 

When I stream using Airplay, the music stops. 

 

In general, the internet orange light flashes repeatedly, so network traffic is ongoing. 

 

Does that help you understand? 

 

The 'review' mentioned Tidal explicitly.  Tidal will cache the entire track locally.

 

So AGAIN, when using this SoTM switch, using Tidal (which was what was used, try and keep up here, reading skills are important), you pull the plug and the music still plays what do you think happens to the sound quality?

[plissken]

10 hours ago, thyname said:

 

‘You keep repeating the same thing over and over again, for years, in hundreds of forums and threads. Eureka!

What's even funnier is that over the years the subjectivist won't answer it because the know that their position on Ethernet cable and switches won't hold up.

 

 

[thyname]

2 minutes ago, plissken said:

What's even funnier is that over the years the subjectivist won't answer it because the know that their position on Ethernet cable and switches won't hold up.

 

 

 

What's even funnier is that you got pretty elaborate replies, with numbers, data, rationale, and everything many times in the past, and yet, you choose to disregard and ignore any of them.

 

It goes like this:

 

Other people: X cable, Y switch, makes a difference for me.

 

You: BS! you must be hallucinating. Pull the Ethernet cable out! Does the sound continue? Yeah!

[plissken]

1 minute ago, thyname said:

 

What's even funnier is that you got pretty elaborate replies, with numbers, data, rationale, and everything many times in the past, and yet, you choose to disregard and ignore any of them.

 

It goes like this:

 

Other people: X cable, Y switch, makes a difference for me.

 

You: BS! you must be hallucinating. Pull the Ethernet cable out! Does the sound continue? Yeah!

 

Links to your unicorn post's of 'What's even funnier is that you got pretty elaborate replies, with numbers, data, rationale, and everything'

 

Cause what you just said certainly hasn't happened.

[The Computer Audiophile]

10 minutes ago, plissken said:

 

The 'review' mentioned Tidal explicitly.  Tidal will cache the entire track locally.

 

So AGAIN, when using this SoTM switch, using Tidal (which was what was used, try and keep up here, reading skills are important), you pull the plug and the music still plays what do you think happens to the sound quality?

My guess is the data has already traversed the noisy switch and unplugging just to listen to one track isn’t practical. Thus, keeping a source of noise connected all the time is a requirement. 

[charlesphoto]

10 hours ago, plissken said:

 

I dare you to answer this one simple question:

 

What happens to all of what you posted when the Ethernet cable is pulled and the music plays on?

 

This question never made sense: if the ethernet cable has transmitted ‘noise’ or jitter, etc to the streamer/DAC, and then the dac/streamer plays that in it’s buffer, won’t it have the same ‘sound’ as the just pulled cable if the buffer continues to play? Alwasy seemed like a straw argument to me...

 

Anyway, just go get a used Cisco 2960 Catalyst (fanless 8, 12.or 16 port models) for anywhere from $25-$200, and have lots of $ left over for gear that will make a bigger difference like amp, speakers, etc. The switch ‘sounds’ better than any consumer ones I used, and with a decent built in SMPS no worrying over power supplies. 

[plissken]

16 minutes ago, The Computer Audiophile said:

My guess is the data has already traversed the noisy switch and unplugging just to listen to one track isn’t practical. Thus, keeping a source of noise connected all the time is a requirement. 

 

You should be able to tell WHEN the cable is removed because the sound should improve. A cable that is unplugged during playback can just as easily be plugged back in during playback.

 

If you can't tell which is which you have a quandary as a subjectivist:

 

Let's walk through the guess you presented:

 

'data has already traversed the noisy switch'

 

Using that we can say that the ultimate fidelity at that point and time is when you unplug the Ethernet cable. That that portion of the playback chain can not be improved upon.

 

So if you have a $90 switch feeding your playback stack, and you have someone randomly unplug and plug the Ethernet cable and you can't tell when that was, then logic dictates that a $1500 switch, or two of them, can't improve your outcome.

 

I've offered before to setup a multi-homed playback computer. I can even do multiple switches and do a HSRP configuration up stream. This will allow full on comparison of a $1800 setup ($1500 switch and $300 cable) and and $100 setup ($90 switch and $10 cable) in real time.

 

[thyname]

3 minutes ago, plissken said:

 

You should be able to tell WHEN the cable is removed because the sound should improve. A cable that is unplugged during playback can just as easily be plugged back in during playback.

 

If you can't tell which is which you have a quandary as a subjectivist:

 

Let's walk through the guess you presented:

 

'data has already traversed the noisy switch'

 

Using that we can say that the ultimate fidelity at that point and time is when you unplug the Ethernet cable. That that portion of the playback chain can not be improved upon.

 

So if you have a $90 switch feeding your playback stack, and you have someone randomly unplug and plug the Ethernet cable and you can't tell when that was, then logic dictates that a $1500 switch, or two of them, can't improve your outcome.

 

I've offered before to setup a multi-homed playback computer. I can even do multiple switches and do a HSRP configuration up stream. This will allow full on comparison of a $1800 setup ($1500 switch and $300 cable) and and $100 setup ($90 switch and $10 cable) in real time.

 

 

LOL!! two people already just told you:

 

20 minutes ago, The Computer Audiophile said:

My guess is the data has already traversed the noisy switch

 

20 minutes ago, charlesphoto said:

This question never made sense: if the ethernet cable has transmitted ‘noise’ or jitter, etc to the streamer/DAC, and then the dac/streamer plays that in it’s buffer, won’t it have the same ‘sound’ as the just pulled cable if the buffer continues to play? Alwasy seemed like a straw argument to me...

 

[plissken]

17 minutes ago, charlesphoto said:

 

This question never made sense: if the ethernet cable has transmitted ‘noise’ or jitter, etc to the streamer/DAC,

 

Ethernet cables transfer data. They don't transfer jitter. They can carry noise.

 

 

17 minutes ago, charlesphoto said:

and then the dac/streamer plays that in it’s buffer, won’t it have the same ‘sound’ as the just pulled cable if the buffer continues to play? Alwasy seemed like a straw argument to me...

 

It only seems like a straw argument until it's realized that buffers only store data. They can't store jitter, they can't store noise.

 

17 minutes ago, charlesphoto said:

 

Anyway, just go get a used Cisco 2960 Catalyst (fanless 8, 12.or 16 port models) for anywhere from $25-$200, and have lots of $ left over for gear that will make a bigger difference like amp, speakers, etc. The switch ‘sounds’ better than any consumer ones I used, and with a decent built in SMPS no worrying over power supplies. 

 

I have at the moment: 8 2960, 4 3750V2, 2 4000 Nexus, 2 3725, some Fortinet, Kemp, and Palo Alto gear sitting here.

[plissken]

3 minutes ago, thyname said:

 

LOL!! two people already just told you:

 

 

 

The question remains unanswered:

 

What happens to the SQ when the cable is pulled. It's a simple question that yet remains unanswered.

 

Those responses are conjecture. I'm asking what actually happens WHEN they do it.

 

It's why I offer $2000 to someones $500 for this to be done in a controlled environment.

[The Computer Audiophile]

59 minutes ago, plissken said:

Ethernet cables transfer data. They don't transfer jitter. They can carry noise.

This is something we should look at more. 

 

Ethernet cables transfer whatever is in the packets. For IP telephony jitter is a huge issue because the tolerances are so much worse than audio. It seems like there is plenty of jitter involved with Ethernet.

 

I'm not following you about Ethernet not transferring jitter. Can you provide more details?

[Jud]

58 minutes ago, plissken said:

They don't transfer jitter. They can carry noise.

 

Yes, exactly.  What happens if/when the noise gets into the DAC chip and clock?  (I recall at least one ESS white paper with info on this.)  It can cause jitter.  And/or it can get into the analog side of the system through ground.  Now I'm just speaking conceptually, and not about whether the levels of this stuff would be audible.

[The Computer Audiophile]

1 hour ago, plissken said:

You should be able to tell WHEN the cable is removed because the sound should improve

That's a very good point. If one cause of sonic change is noise and that noise is coming from upstream of the DAC Ethernet interface, one should be able to notice when the cable is unplugged. 

 

The funny thing is, I have a friend who has always unplugged his Ethernet for playback because he hates the sound when it's plugged in. This person has no idea how any of this works, he just uses his ears. 

 

I've also heard about measurements with and without Ethernet cables plugged into a DAC and being able to see differences on the analog output. I need to dig further into this to see if these differences matter and what they actually show.

[Jud]

Just now, The Computer Audiophile said:

I'm not following you about Ethernet not transferring jitter. Can you provide more details?

 

Timing of the bits through an Ethernet or USB cable (to an async input) shouldn't matter because they go into a buffer.  Conceptually, you could be typing ones and zeroes with totally inconsistent timing, and as long as they went into a buffer somewhere and were clocked out accurately, no worries.  There are two aspects of noise that I believe could conceptually make a difference regarding jitter: (1) The DAC chip compares signal to ground in order to determine the timing of changes from 1 to 0 or vice versa.  If there's noise on ground, the timing changes - jitter.  (2) Noise getting to sensitive clock circuitry could make the clock less accurate.

[The Computer Audiophile]

3 minutes ago, Jud said:

 

Timing of the bits through an Ethernet or USB cable (to an async input) shouldn't matter because they go into a buffer.  Conceptually, you could be typing ones and zeroes with totally inconsistent timing, and as long as they went into a buffer somewhere and were clocked out accurately, no worries.  There are two aspects of noise that I believe could conceptually make a difference regarding jitter: (1) The DAC chip compares signal to ground in order to determine the timing of changes from 1 to 0 or vice versa.  If there's noise on ground, the timing changes - jitter.  (2) Noise getting to sensitive clock circuitry could make the clock less accurate.

I struggling to understand how these buffers actually help rather than conceptually should help. Doesn't the receiving end just buffer exactly what has been delivered? Ive used many IP phones that have huge jitter issues. A buffer should've solved the issue? A reclocker sounds more appropriate. 

 

I honestly don't know, so I'm just asking.

[Jud]

15 minutes ago, The Computer Audiophile said:

Doesn't the receiving end just buffer exactly what has been delivered?

 

Then there'd be little reason to have a buffer in a local file playback situation (as opposed to streaming).  At least my conceptual understanding is that the bits in the buffer are values in a location that stores those values but doesn't store arrival times.  So the only thing controlling the timing (jitter) of the bits as they come out of the buffer in a DAC with async input is the local DAC clock.

 

Edit: Ever fly Southwest Airlines?

[plissken]

18 minutes ago, The Computer Audiophile said:

This is something we should look at more. 

 

Ethernet cables transfer whatever is in the packets. For IP telephony jitter is a huge issue because the tolerances are so much worse than audio. It seems like there is plenty of jitter involved with Ethernet.

 

I'm not following you about Ethernet not transferring jitter. Can you provide more details?

 

Jitter is simply this: Take a signal with a certain specified clock rate like 125Mhz and and allow that rate to +/- a bit (skew). That is a form of jitter.

 

For one thing a certain amount is allowed. For a second we have input and output buffers and most sit between clock domain boundaries. Buffers eliminate jitter 100% guaranteed.

 

The packets remain unaffected by jitter once they've hit a buffer. The final one being in the DAC where the audio clock rate is applied.

 

Pulling the Ethernet cable, technically, introduces the worst kind of jitter imaginable. Many high end streamers have enough buffer to hold 30-240 seconds of audio (format dependent).

 

Jitter is never stored, It's never part of the data.

[plissken]

26 minutes ago, Jud said:

 

Yes, exactly.  What happens if/when the noise gets into the DAC chip and clock?

 

Then a dipshit designed the DAC.

[Jud]

Just now, plissken said:

 

Then a dipshit designed the DAC.

 

Noise is always going to be present, the only question is how much (how effectively the design protects against that noise).  Lots of methods of isolation from transmitted noise are noisy themselves, so complete isolation isn't the complete answer either.