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

no you do not. And yes, i have listened, jsut to be open minded.

Note the argument is stringer than some data above would suggest. For the most part it does nto matter if the jitter is the same or not between costly and cheap-o hubs, because THAT JITTER DOES NOT APPEAR AT THE DAC CHIP ITSELF.   In fact, on USB interfaces, the bits are read in essentially asynchronusly into a buffer. All timing is basically lost.  They are then, at least in really good DACs, clocked out as precisely as possible. This costs.  QED.

Now a good network with good throughput will minimize buffer underruns, and will allow the highest bit depth, over/up sampling etc.

So yes, networks matter but not int he respect these high end units suggest.

Oh, and they dont sound better. Many things do, not those.

One of the claims made for these audio switches is they generate a better signal, better timing or click,  hence the need for  external clocks which is another nonsense claim for home audio. Click is nothing but jitter and as you can see in the above plot there is no difference in jitter. USB is not used, the test is ran through ethernet, but USB would be just as good.

@djones51 I am honesty trying to understand your post.

Is this jitter measured in the Ethernet link? How jitter in the link could affect sound if there is no "Ethernet jitter" to speak of from the NIC to the PCIe bus/refclk?

Ethernet jitter ceases to exist at the PCIe layer, it just can’t because of the electrical design.

I am honestly trying to understand, because once "out" of the "the Ethernet stack in the NIC" and hits the PCIe bus the only jitter there is, is the PCIe jitter from the different REFCLK clock architectures, and now we are talking 100MHz for PCIe 3 and 4, PCIe5 has a different refclk architecture and there we are talking phase jitter on the ranges 12 kHz to 20 MHz and 10 kHz to 50 MHz.

Needless to say that a NIC binds to the bus’s refclk and nothing else, it is just electrically impossible.

In the case that the streamer/DAC uses different protocol than PCIe for their bus architecture whichever clock they use for reference, this would be "internal-linked" to the component refclk by which all the bus timing functions would be derived from.

Again, I am tryin to understand how jitter in the Ethernet link can affect anything in the component bus refclk.

it is my understanding that if anything it is the component’s refclk which would affect the music timing, and this refclk has absolutely nothing to do with the Ethernet SSM, as a matter of fact I am not aware of any protocol for bussing that is aware of any other ref clock that does not participate in the bus and there I am certain that there is no way an SSM would be even accurate to even to execute any of the Link Inspector Commands in the bus.

I know this might be boring but I want to understand, so I kindly ask you if you can teach/explain the point of measuring jitter at the Ethernet layer and how it affects anything beyond the NIC/bus adapter.

Are we saying the same thing?

Thank you

teach/explain the point of measuring jitter at the Ethernet layer and how it affects anything beyond the NIC/bus addapter. 

The point of measuring jitter is because the companies that make these switches claim their switch will generate a better signal with less "jitter" on the line not in the packet. The test shows this is nonsense as well.

No.