SOtM sNH-10G Network Switch Review

plissken · February 10, 2019

52 minutes ago, Superdad said:

You’re calling @PeterSt ignorant?

What a sweet guy you are. No wonder you are so well liked...

In what way is my challenging his POV about the operations that involve keeping a network connection up/up and the the 'noise' it generates

VS

all the other caching operations that go on even on a newly installed OS and optimized is incorrect.

Either it's ignorance or it's deception. Which is it?

Because it is certainly isn't correct. And it's already been proven.

Here you go and you are most welcome to debunk if you can...

plissken · February 10, 2019

42 minutes ago, incus said:

But what experiments have you done to say you can't hear that noise? There is a growing body of listening impressions on that big topic listing that shows different sounds to different processors throttled in different ways, lower latency software, RAM booted software, etc. Isn't this presumably reducing the audible effects of those processes? There is ignorance from inexperience that is forgiven with enlightenment and then there is willful ignorance despite enlightenment which is unforgivable.

You let me know when you want to put on the blindfold.

If you can't trust your ears neither can anyone else.

incus · February 10, 2019

4 minutes ago, plissken said:

You let me know when you want to put on the blindfold.

If you can't trust your ears neither can anyone else.

Let me know when you want to take it off.

plissken · February 10, 2019

3 minutes ago, incus said:

Let me know when you want to take it off.

I'm quite comfortable in literally trusting my ears. What's your excuse?

PeterSt · February 11, 2019

8 hours ago, incus said:

if all the packets inside the DAC's receiver chip have already passed through the network to get there - no matter when or where it was buffered before - and IF there is any kind of phase noise influence (positive of negative) and/or electrical noise that carries over from the upstream network - then that would ALREADY be there in the signal now being taken in by the DAC.

You do understand digital, do you ?

Oh, wait ...

PeterSt · February 11, 2019

7 hours ago, plissken said:

In what way is my challenging his POV about the operations that involve keeping a network connection up/up and the the 'noise' it generates

VS

all the other caching operations that go on even on a newly installed OS and optimized is incorrect.

In all ways. Just because you are so keen to leave out the proper context.

7 hours ago, plissken said:

Here you go and you are most welcome to debunk if you can...

Maybe @Superdadcan't (you were asking him) but I can do that on behalf of him;

If you are so good with Process Monitor you might just as well look at a somewhat rougher level and count the task switches. For an optimized system (like with AO) this comes to 46 million switches per second during audio playback (over USB). Allow me to be 50% off for your system. Now ignorant me comes along; In that same system with 46M task switches as by miracle it becomes 680,000. *)

Now you are of course going to show me that figure because you can do that too. But that is only step one. Step two would be that you now in *that* context again present your whatever caching and again would say that "these few more" surely won't make any difference.

Moral: Everything makes a difference but one has to apply first everything in order to detect its relative effect. Be that a technical matter like a PMI Counter or be that audible effect. Of course, if I'd like to present that an electrical difference of 10mV of noise really won't matter on 500mV of noise (think power supply) then everybody will think that is correct. But if that 10mV is superimposed on 10uV the story becomes a bit different. That, in order to get there, I first had to eliminate a 100 other sources of noise is something else, but crucial context.

Someone was talking about that this is not about winning or losing. But you lose.

*) IIRC this was for a W8 system and by now 6-7 years ago. Today's W10 will be very different, and varying per Build. Also my own software regarding this evolved quite a bit (focusing W10).

rickca · February 11, 2019

14 hours ago, PeterSt said:

Hmm ... Is "not that I know of" anything for an answer ?

Peter it sounds like you don't believe the stuff that Alex and John Swenson describe ... upstream phase noise fingerprint affecting downstream components and getting past many kinds of isolation techniques? Am I misinterpreting what you're saying?

plissken · February 11, 2019

2 minutes ago, PeterSt said:

In all ways. Just because you are so keen to leave out the proper context.

Maybe @Superdadcan't (you were asking him) but I can do that on behalf of him;

If you are so good with Process Monitor you might just as well look at a somewhat rougher level and count the task switches. For an optimized system (like with AO) this comes to 46 million switches per second during audio playback (over USB). Allow me to be 50% off for your system. Now ignorant me comes along; In that same system with 46M task switches as by miracle it becomes 680,000. *)

Now you are of course going to show me that figure because you can do that too. But that is only step one. Step two would be that you now in *that* context again present your whatever caching and again would say that "these few more" surely won't make any difference.

What I'm saying is you can't tell the difference and we can easily present different load for the OS to run.

Let me know when you are up for some blind testing. We can setup an Intel box with Prime 95. I can control it from remote, run it headless, and you tell me during playback when the system is under increased load.

2 minutes ago, PeterSt said:

*) IIRC this was for a W8 system and by now 6-7 years ago. Today's W10 will be very different, and varying per build. Also my own software regarding this evolved quite a bit (focusing W10).

If you are talking about my screenshot it was Win10Pro X64. I forget the build #.

PeterSt · February 11, 2019

4 minutes ago, rickca said:

14 hours ago, PeterSt said:

Hmm ... Is "not that I know of" anything for an answer ?

Peter it sounds like you don't believe the stuff that Alex and John Swenson describe ... upstream phase noise fingerprint affecting downstream components and getting past many kinds of isolation techniques? Am I misinterpreting what you're saying?

Hey Rick. I guess, like with @incus, many of you guys know a lot more about this than may seem from my responses (and btw, who am I). So no, it is about the difficulty in describing what happens where. Now since referring once again to that larger post from by now two days ago apparently does not help, here a smaller retry in different wording:

Quote

if all the packets inside the DAC's receiver chip have already passed through the network to get there - no matter when or where it was buffered before - and IF there is any kind of phase noise influence (positive of negative) and/or electrical noise that carries over from the upstream network - then that would ALREADY be there in the signal now being taken in by the DAC.

So that text again (from incus). I'll try it as short as possible:

-----

If you would record that, like in a non-volatile buffer, would the added phase noise (error) be recorded ?

Of course not, because this is digital. So transfer errors left alone, this would just be a copy like a copy of a Word document.

-----

That is actually all there is to say. And oh, whether that copy resides in non-volatile or volatile memory, doesn't make a difference. It is only that the "buffer" we seem to talk about would merely be volatile.

The problem with making things clear, emerges here:

Once this copy is in-memory (still pushing out towards the DAC and makes sound), you can pull the Ethernet cable to eliminate the Switch, but really nothing - NO-THING - will change to that copy of the data. How could it. It already was 100% fine (after possible error-correction because computers tend to do that ).

Done.

No wait, ... but it was the stance that pulling that cable/Switch would change sound ?

YES. Because in real-time the noise influence (Phase Noise if you want) signature is changing. The digital data stays the same (0's and 1's don't interpret differently). So envision that nice analogue very low level test signal, think 30uV), and when the cable is pulled that noise becomes 25uV. This really isn't hard to imagine, I'd say. This is because this is analogue noise and it may come along with the connection to the Switch and be gone when that connection is pulled.

Now, did that change anything to the digital data ?

PS: It is not allowed to claim that 5uV is not audible because it is about the principle. The analogue signal has changed and thus that could be audible. And now I didn't even talk about jitter, which actually is ahead of that analogue output signal, and where the noise in the digital signal (which in the end is electrical analogue) influences jitter. Peaks and valleys (1's and 0's) don't trigger at the same time when noise is added (a peak of noise triggers early). So pulling the Switch will lower jitter.

And the recorded data (or data in the buffer) will still be 100% equal in both pulled and not-pulled situations.

More clear now ?

Jud · February 11, 2019

7 hours ago, rickca said:

Peter it sounds like you don't believe the stuff that Alex and John Swenson describe ... upstream phase noise fingerprint affecting downstream components and getting past many kinds of isolation techniques? Am I misinterpreting what you're saying?

My impression (I could be wrong) is that though this is what they believe to be happening, they have not yet had a chance to measure and see whether or not it is definitely the case.

Jud · February 11, 2019

7 hours ago, plissken said:

What I'm saying is you can't tell the difference and we can easily present different load for the OS to run.

Let me know when you are up for some blind testing. We can setup an Intel box with Prime 95. I can control it from remote, run it headless, and you tell me during playback when the system is under increased load.

If you are talking about my screenshot it was Win10Pro X64. I forget the build #.

Way back near the dawn of digital, people like Ed Meitner were already discussing “logic induced modulation,” and right up to the present day folks like ESS talk in white papers about lowering noise getting into the chip. It’s a situation where the level of noise may not be quite so important as even small changes in it (changes in noise on ground = jitter at the clock), so at least theoretically you don’t want things in the playback chain to be changing noise characteristics while engaging in playback.

To what extent this or anything to do with jitter may be audible has always been a subject of some discussion and controversy.

MarkS · February 11, 2019

I love these subjective vs. objective based threads like this one. I am 100% sure I hear differences in cables, switches, etc. - I think.

EdmontonCanuck · February 11, 2019

The thing that seems all "flat earth" to me is that some people believe that "noise" gets stored with a digital stream when it's buffered and is transmitted along the chain to other digital devices to eventually manifest itself when it undergoes analog conversion.

incus · February 11, 2019

23 minutes ago, EdmontonCanuck said:

The thing that seems all "flat earth" to me is that some people believe that "noise" gets stored with a digital stream when it's buffered and is transmitted along the chain to other digital devices to eventually manifest itself when it undergoes analog conversion.

You got the reference backwards. Flat earth is old dogma - which in this case is that bits are bits. Round earth is new discoveries of ways in which phase noise from prior clocking may indeed seem to show up later. Not to mention electrical noise traveling with the signal (not stored in it) from server, switch, endpoint, whatever does the buffering, through all their power supplies, etc. All apparently brought to the USB receiver chip to deal with unless it's mitigated along the way. Obviously a great clock at the USB chip with great isolation characteristics would do a lot to mitigate all this. Seems to me Master Clock connections on USB receiver chips would be something we should see more widely adopted (I know they already exist) now that all these other kinds of master clocking have cropped up and there seems to be some consensus about their benefits.

Superdad · February 11, 2019

10 hours ago, Jud said:

Way back near the dawn of digital, people like Ed Meitner were already discussing “logic induced modulation,” and right up to the present day folks like ESS talk in white papers about lowering noise getting into the chip. It’s a situation where the level of noise may not be quite so important as even small changes in it (changes in noise on ground = jitter at the clock), so at least theoretically you don’t want things in the playback chain to be changing noise characteristics while engaging in playback.

To what extent this or anything to do with jitter may be audible has always been a subject of some discussion and controversy.

Seems a good place to reprint a post of @JohnSwenson's from October 2017:

The hypothesis goes thusly:

ALL crystal oscillators exhibit frequency change with power supply voltage change. This is known and well measured. A cyclical change in voltage causes a cyclical change in frequency which shows up in phase noise plots. For example if you apply a 100Hz signal to the power supply of the oscillator you will see a 100Hz spur in the phase noise plot.

A circuit that has a digital stream running through it will will generate noise on the power and ground planes of the PCB just from the transistors turning on and off that are processing that stream. This effect is very well known and measured. Combine this with the previous paragraph and you have jitter on the incoming data stream producing varying noise on the PG planes that modulates the clock increasing its jitter.

The above has been measured.

But shouldn't ground plane isolation and reclockers fix this? At first glance you would think so, but look carefully at what is happening. What is a reclocker? A flip flop. The incoming data with a particular phase noise profile goes through transistors inside the flip flop. Those transistors switching create noise on its internal PG traces, wires in the package and traces on the board. This noise is directly related to the phase noise profile of the incoming data. This PG noise changes the thresholds of the transistors that are clocking the data out thus overlaying the phase noise profile of the local clock with that of the clock used to generate the stream that is being reclocked. This process is hard to see, so I am working on a test setup that generates a "marker" in the phase noise of the incoming clock so it becomes easy to see this phase noise overlaying process.

This process has always been there but has been masked by the phase noise of the local clock itself. Now that we are using much lower phase noise local clocks this overlying is a significantly larger percentage of the total phase noise from the local clock.

Digital isolators used in ground plane isolation schemes don't help this. Jitter on the input to the isolator still shows up on the output, with added jitter from the isolators. This combination of original phase noise and that added by the isolator is what goes into the reclocking flip flop, increasing the jitter in the local clock. Some great strides have been made in the digital isolator space, significantly decreasing the added phase noise which over all helps, but now the phase noise from the input is a larger percentage, so changes to it are more obvious.

The result is that even digital isolators and reclocking don't completely block the phase noise contribution of the incoming data stream. It can help, but it doesn't get rid of it.

For USB (and Ethernet) it gets more complicated since the data is not a continuous stream, it comes in packets, thus this PG noise comes in bursts. This makes analysis of this in real systems much more difficult since most of the time it is not there. Thus any affects to an audio stream come and go. Thus just looking at a scope is not going to show anything since any distortion caused by this only happens when the data over the bus actually comes in. To look at anything with a scope will take synchronizing to the packet arrivals. Things like FFTs get problematic as well since what you are trying to measure is not constant . It will probably take something like wavelet analysis to see what is really happening.

The next step in my ongoing saga is to actually measure these effects on a DAC output. Again I have to build my own test equipment. The primary tool is going to be an ADC with a clock with lower phase noise than the changes which occur from the above. AND it needs to be 24 bits or so resolution. You just can't go out and buy these, they don't exist. So I build it myself.

I have done the design and have the boards and parts, but haven't had time to get them assembled yet. Then there is a ton of software to make this all work. Fortunately a large part already exists, designed to work with other systems but I can re-purpose it for this.

So it's not going to be right away, but hopefully not too off in the future I should be able to get to actually testing the end to end path of clock interactions all the way to DAC output.

John S.

===========

FYI, his elaborate clock test set up--we call it the Golden Gate Bridge--has been through a couple of iterations and John has been working ever more actively on it--even this very day. But mostly in-between product development work.

Ralf11 · February 11, 2019

well, same for output resistance & Temperature variation

but the key is "how much"...

incus · February 11, 2019

12 minutes ago, Superdad said:

Seems a good place to reprint a post of @JohnSwenson's from October 2017:

The hypothesis goes thusly:

ALL crystal oscillators exhibit frequency change with power supply voltage change. This is known and well measured. A cyclical change in voltage causes a cyclical change in frequency which shows up in phase noise plots. For example if you apply a 100Hz signal to the power supply of the oscillator you will see a 100Hz spur in the phase noise plot.

A circuit that has a digital stream running through it will will generate noise on the power and ground planes of the PCB just from the transistors turning on and off that are processing that stream. This effect is very well known and measured. Combine this with the previous paragraph and you have jitter on the incoming data stream producing varying noise on the PG planes that modulates the clock increasing its jitter.

The above has been measured.

But shouldn't ground plane isolation and reclockers fix this? At first glance you would think so, but look carefully at what is happening. What is a reclocker? A flip flop. The incoming data with a particular phase noise profile goes through transistors inside the flip flop. Those transistors switching create noise on its internal PG traces, wires in the package and traces on the board. This noise is directly related to the phase noise profile of the incoming data. This PG noise changes the thresholds of the transistors that are clocking the data out thus overlaying the phase noise profile of the local clock with that of the clock used to generate the stream that is being reclocked. This process is hard to see, so I am working on a test setup that generates a "marker" in the phase noise of the incoming clock so it becomes easy to see this phase noise overlaying process.

This process has always been there but has been masked by the phase noise of the local clock itself. Now that we are using much lower phase noise local clocks this overlying is a significantly larger percentage of the total phase noise from the local clock.

Digital isolators used in ground plane isolation schemes don't help this. Jitter on the input to the isolator still shows up on the output, with added jitter from the isolators. This combination of original phase noise and that added by the isolator is what goes into the reclocking flip flop, increasing the jitter in the local clock. Some great strides have been made in the digital isolator space, significantly decreasing the added phase noise which over all helps, but now the phase noise from the input is a larger percentage, so changes to it are more obvious.

The result is that even digital isolators and reclocking don't completely block the phase noise contribution of the incoming data stream. It can help, but it doesn't get rid of it.

For USB (and Ethernet) it gets more complicated since the data is not a continuous stream, it comes in packets, thus this PG noise comes in bursts. This makes analysis of this in real systems much more difficult since most of the time it is not there. Thus any affects to an audio stream come and go. Thus just looking at a scope is not going to show anything since any distortion caused by this only happens when the data over the bus actually comes in. To look at anything with a scope will take synchronizing to the packet arrivals. Things like FFTs get problematic as well since what you are trying to measure is not constant . It will probably take something like wavelet analysis to see what is really happening.

The next step in my ongoing saga is to actually measure these effects on a DAC output. Again I have to build my own test equipment. The primary tool is going to be an ADC with a clock with lower phase noise than the changes which occur from the above. AND it needs to be 24 bits or so resolution. You just can't go out and buy these, they don't exist. So I build it myself.

I have done the design and have the boards and parts, but haven't had time to get them assembled yet. Then there is a ton of software to make this all work. Fortunately a large part already exists, designed to work with other systems but I can re-purpose it for this.

So it's not going to be right away, but hopefully not too off in the future I should be able to get to actually testing the end to end path of clock interactions all the way to DAC output.

John S.

===========

FYI, his elaborate clock test set up--we call it the Golden Gate Bridge--has been through a couple of iterations and John has been working ever more actively on it--even this very day. But mostly in-between product development work.

Thank you.

Jud · February 11, 2019

23 minutes ago, Ralf11 said:

well, same for output resistance & Temperature variation

but the key is "how much"...

Not only.

The key is how rapid the variation is, as much as or more than absolute level. Something that varies over minutes or hours may as well take a glacial age with respect to causing jitter.

Jud · February 11, 2019

25 minutes ago, incus said:

Thank you.

But notice: The measurement hasn’t happened yet. And even after that, we’re left to ponder the question of how significant/audible it might be.

mansr · February 12, 2019

1 hour ago, Jud said:

But notice: The measurement hasn’t happened yet.

How many years has it been?

JohnSwenson · February 12, 2019

19 hours ago, PeterSt said:

No wait, ... but it was the stance that pulling that cable/Switch would change sound ?

YES. Because in real-time the noise influence (Phase Noise if you want) signature is changing. The digital data stays the same (0's and 1's don't interpret differently). So envision that nice analogue very low level test signal, think 30uV), and when the cable is pulled that noise becomes 25uV. This really isn't hard to imagine, I'd say. This is because this is analogue noise and it may come along with the connection to the Switch and be gone when that connection is pulled.

Now, did that change anything to the digital data ?

PS: It is not allowed to claim that 5uV is not audible because it is about the principle. The analogue signal has changed and thus that could be audible. And now I didn't even talk about jitter, which actually is ahead of that analogue output signal, and where the noise in the digital signal (which in the end is electrical analogue) influences jitter. Peaks and valleys (1's and 0's) don't trigger at the same time when noise is added (a peak of noise triggers early). So pulling the Switch will lower jitter.

And the recorded data (or data in the buffer) will still be 100% equal in both pulled and not-pulled situations.

More clear now ?

The pulling the plug thing is what actually got me looking into this.

A while back I had a prototype of one the streamers on the bench feeding a little inexpensive DAC ($110) feeding some inexpensive Senheiser headphones($69) when I accidentally unplugged the Ethernet cable and the increase in sound quality blew me away. There was about 1 minute of music stored in the streamer so I got 1 minute of REALLY good sounding music.

So yep, pulling the plug DID make a big difference, but it wasn't a "test", there was no expectation involved.

John S.

mansr · February 12, 2019

Just now, JohnSwenson said:

the increase in sound quality blew me away

Yeah, right. Did your wife in the kitchen notice it too?

thyname · February 12, 2019

1 minute ago, JohnSwenson said:

The pulling the plug thing is what actually got me looking into this.

A while back I had a prototype of one the streamers on the bench feeding a little inexpensive DAC ($110) feeding some inexpensive Senheiser headphones($69) when I accidentally unplugged the Ethernet cable and the increase in sound quality blew me away. There was about 1 minute of music stored in the streamer so I got 1 minute of REALLY good sounding music.

So yep, pulling the plug DID make a big difference, but it wasn't a "test", there was no expectation involved.

John S.

‘So please hurry up and take those measurements so that we can “prove” it to these pseudoscience a*holes!

JohnSwenson · February 12, 2019

1 minute ago, mansr said:

How many years has it been?

It's been over two years now.

I actually had everything all built, FPGA code written and started trying it out about two months ago and found out the system as a whole did not work. The system consisted of 7 boards tied together with a forest of coax and board to board connectors. I deliberately made the system highly modular so many different tests could be performed.

Well that was a BAD idea! All those connectors proved very problematic, I could never get the whole system to be working together at the same time. Some connector or other was always working poorly, I just could not get it all working together.

So back to the drawing board. I replaced 5 of the boards into one board, getting rid of almost all the connections, did the highest quality connections I could come up with on the board etc. I just finished the layout of this board a few minutes ago, so now its get the board fabricated and solder all these parts on. Then I try again.

John S.

JohnSwenson · February 12, 2019

8 minutes ago, mansr said:

Yeah, right. Did your wife in the kitchen notice it too?

I was listening to headphones, how could that happen?

John S.

SOtM sNH-10G Network Switch Review

User Feedback

Recommended Comments

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Create an account or sign in to comment

Create an account