EE8 which has a fancy clock vs Netgear 108 switch made no significant difference in my set up.
Changing the cheapo SMPS on the Netgear (no using EE8) made a clear difference. Which suggests that noise IS a factor.
It’s possible that the reason the fancy clock in the EE8 made no difference is down to the ND555 buffering tracks and playing from there which would reduce the impact of jitter created by a switch.
Not an obsession - just reporting what my ears heard and a hypothesis as to why 
Any half-decent dac will reclock the signal and reduce any jitter, so if there’s any improvement it would be noise. If it’s jitter it’s as much the DACs fault as any other components.
Sure, I’m not trying to argue that noise isn’t an issue. Just that noise from cheap power supplies (which coincidentally have upgrade options which appeal to one’s appetite for retail therapy) might not be the only issue.
Chris, yes I agree I think there is a misguided obsession by some with ‘network’ noise… perhaps some not really understanding what is happening, and then audible outcomes being justified by some elaborate theories.
Any powersupply, whether it be switched or linear can produce noise if not designed correctly… and both can be horrendous.
A powersupply that doesn’t filter adequately the power supply lines or properly decouple the ground or return for the task in hand can cause issues with coupling, common mode noise, and clock phase modulation (jitter). All of these resultant artefacts can be audible .
A well designed audio host should be largely isolated from such Ethernet based noise, and my experience with the current Naim streamers bears this out. However that is not to say there are not coupling issues elsewhere than can be audible… it’s just I suspect it’s nought to do with Ethernet… and is just as likely to occur with mains leads , SPDIF or interconnects or any directly connected coupled lead. The fact I have heard no one on this forum ever mention that ‘Ethernet’ noise comes and goes when listening to a track on their streamer to me is likely evidence of this… (though I accept a noisy switch clock could create noise coupling with no data actually being sent… but a noticeable sonic shift would be achieved in such cases by disconnecting the Ethernet lead… even whilst a track was playing from memory)
So if I am understanding things correctly it appears to me that those of us using high end streamers ie Naim ND555, Linn KDS, dCS Rossini (and any others I may have left out) will not really benefit from toys such as the EE8, Sonore Ether Regen, Innuos Phoenix etc as they appear to be solutions for non existent Ethernet “noise” problems.
Not withstanding others findings this is the conclusion I have started settling into. I trust that even if there were ethernet “noise” the above mentioned streamers are sophisticated enough to have mitigation protocols already built into their streaming board circuitry. This is sort of confirmed by the fact that the manufacturers of my two streamers, Linn and dCS, continue to advocate for “compliant” non fancy ethernet cables and standard ethernet switches.
Best
Gregg
Not quite, you may benefit or at least create a sonic shift that you may perceive as better SQ, nothing wrong with that if you are happy, but in ways that are not really anything to do with your local data network…(and I suspect one is not actually changing the SQ, just the perceived performance … but that is another matter and I don’t really want to open that can of worms)
And because of this I suspect this is why some manufacturers recommend compliant Ethernet and leave conducted noise issues to be dealt with separately … where you may have more control and/or be more deterministic.
I can’t speak for other brands, but I think Naim have improved their streamers level of immunity to electrical noise with the current range. My old NDX seemed to expose differences between switches, servers, FLAC vs WAV, and various other upstream issues more than my NDX2 now does.
I also find, as I think Simon has observed too, that using SPDIF out into a separate DAC further reduces these effects to the point where to my ears they are negligible.
On the other hand, there seem to be those who hold a black and white view that a competently designed DAC is totally immune to any differences in digital inputs, and that they are defective by design if this is not the case. That claim seems a step too far to me.
I believe Linn advocate optical ethernet (which is added to the latest, the greatest Klimax DSM/3).
Not what I found from my own experience but it depends on lots of things, including musical taste and priorities
My Linn dealer, a highly respected person in the trade, confirms that there are noises from the copper ethernet, and I actually verified it myself with my Klimax DSM/3 (Organik) by comparing the 2 inputs - copper vs. optical. I do not use anything fancy, just a simple CISCO 2960G which can support both copper and optical at the same time.
FIFY
Ja, a salesman. 
He may be, but he is also a postgrad from a well-known university in the south of England.
@suzywong, I really admire your powerful, highly paid professional occupation, you must be from a wealthy, high society? I am just a sewage worker of elementary education, living in the ghetto of the working class town, San Jose, CA, US.
A very very useful occupation to the community. D@mn sight more useful than designing spacecraft!
I’m a spacecraft designer 
My commiserations 
ditto.
Not my finding at all. Switching from a cheap Netgear switch to an Innuos Phoenix Net made an obvious, clear improvement.
Well it’s not rocket science…
Ah, hmm, actually maybe it is!
I have nothing against the phoenix usb or any innuos products, but i have a reservation on spending my hard earned cash on something too expensive for what it is, i just want to quote a statement from the hqplayer developer on the roon forum, which makes sense to me;
Since the USB clock is not used for audio. And master clock responsible for clocking audio is owned by the DAC, I don’t see any benefit in reclocking USB (or Ethernet for that matter either). These clocks have no relation to audio clocks, they just facilitate data transfer between two RAM buffers.