Yes, and I was referring specifically, although not limited to the, EM from the circuitry converting the analogue signals into discrete digital data in a timed stream.
There are other considerations that drive noise from the imperfections in the twisted pairs and other physical electrical and RF considerations.
Here is a white paper from TI showing how noise can be reduced from physical and electrical considerations of Fast Ethernet connections
2 Likes
Cool, thanks for the info @Simon-in-Suffolk. I am not a hardware engineer, so I will have to think how the baud rate can influence the bit rate in a low bandwidth environment, how it can impact the SQ of a streamer/DAC.
So based on the discussions in this thread, can I assume that the only benefit of the boutique, exotic network swithes and audiophile copper ethernet cables is the mitigation of the common mode noises for those who have their HIFI systems in some kind of electrically noisy environments.
And also some consumer audiophile switches concentrate on having highly stable serialisation clocks, to help mitigate phase noise coupling into susceptible streamer/network DACs with perhaps weaker decoupling at the other end of the Ethernet segment.
2 Likes
Sure, but who here has tried an improved clock?
It’s one of the main design features of the Innuos PhoenixNET switch, which is used by multiple members here, including those with ND555 streamers, to great acclaim.
Yes that is the serialisation clock I am referring to.
Its probably a lot cheaper to use such a consumer audiophile switch with a separate high precision clock input than use a IEEE 1588 industrial switch with a clock accuracy of 80 PPM or less.
I would suggest if you used two ND555 - one as a digital streamer and the other as a DAC - then you would hear no or minimum benefit however.
1 Like
It also remains to be seen in my context of NGKDSM whether it makes much of a difference.
I will compare the options and use my ears. At least now I understand the mechanism through which improvement could happen. I find testing blind without a sensible hypothesis or logic of why a change might make a difference counterproductive and potentially dangerous long term. Different is not always better.
Optimised ethernet v native optical sfp v native wifi.
1 Like
remember these are the same things
So the emi from clock recovery still applies in both options? Perhaps you could expand on that. Would be helpful if I understand. 
Makes sense, even theoretically they are the same thing.
1 Like
For the purpose of emi noise feom reclocking yes. But i would also expect differences in
A) their decoupling from background levels of common mode noise in the network
B ) any additional noise from the cable or RF in the case of wifi?
Just had chance to read. This is great thanks.
On the other hand if you just want to listen to music without bothering with the gear the Cisco 2960 is still a very good allround choice. Or a GS108T/GS308 for a bit more pace and edge. At least while one wait out the ongoing discussions.
2 Likes
One practical step from this conversation I locked down my ubiquiti port configuration for the hifi end of my network to 100mbs full duplex and switched on port isolation for those ports.
Thanks. I think I will persist in optimising my ubiquiti setup first. The combination of cleaning up cables (ethernet separation from power), multiple switches and correct use of utp cables and shielded cables (earthed at one end) has made a massive difference already. Also just added this change. I will wait for ngkdsm to be in position and well run in before I try a different switch.
Naim Streamers don’t operate very well over half duplex - I tried once as an experiment. They will auto negotiate to full duplex fast ethernet on a switch, and obviously half duplex fast ethernet on a hub.
You don’t need to really use VLANs with the streamers on a switched setup on a home network - but no harm in doing so if you want.
1 Like
Thanks. Also will be straightforward to play with a hifi dedicated vlan. Already running 4 vlans. I will leave things as they are for a few days then switch back to auto negotiation and see if I hear it. Then play with vlans. Thanks.
just remember you need to route between VLANs with each VLAN having its own subnet and gateway address, you can’t switch between them - and depending on the capability of your router and your configured helpers if any - certain applications, like DLNA, and SSDP can stop working between VLANs.
1 Like
Yes my firewall has the vlans fully locked down, except for where I override eg to my pihole dns. The bit that would be most irritating to break will be the roon discovery step - thats always a little hit and miss already. I was worried port isolation would kill that but so far ok.
Edit - i could easily route by roon server but my ipad as the control device would need to be on that vlan. Mind you i could probably route that as well.
hmm different things. You don’t really ‘lock’ anything down with a broadband router firewall, you simply control port forwarding, pin holing on IPV6 and whether you allow unsolicited inbound flows. Your broadband router effectively acts as a PAT (Port Address Translator) across the public address and RFC 1918 address (home private address) boundary - which by its nature acts as a basic firewall. Your broadband router will need to route between VLANs as well as the internet via PAT.
To ‘lock’ things down one need to limit ports etc for outbound initiated flows. Most broadband routers will not do this, but you can do on many device like Windows and OSX system firewalls.
You cant easily route Roon core - with out routing multicast and possibly setting up helpers. It needs to reside in the same subnet as its playback devices and control points…
Many home applications are not designed to be routable, other than to talk via PAT to the internet.
2 Likes