Managed switches (and more to the point - people buying them because āmore expensive must mean better, right?ā) have been an absolute nightmare for me for the last 20 yearsā¦
ā¦as have poorly performing Ethernet extenders (Ethernet over Powerline, WiFi to Ethernet Bridges, Ethernet over Coax etc.) that end up being used because āitās impossible for me to run an Ethernet cableā ā¦ the number of times that Iāve had someone check for problems by just temporarily running an ethernet cable and the kit has then suddenly started working fine but yet itās still seemingly presumed to be down to the streamer manufacturer to āmake it workā with the networking kit that isnāt working correctly rather than making the networking kit that isnāt working correctly work correctly.
People always presume that networking is difficult but it really isnāt ā¦ issues are almost invariably caused by people taking shortcuts. I often get asked āWhat features and functionality do you need for your kit to work so I know what to ask forā but we donāt need anything specific or unusual outside of the defined and accepted Ethernet specs - the networking kit just needs to work correctly which can be more of an issue.
ISP supplied routers have always been a bit of a grey area - I did some testing quite a few years ago on several different versions of āHomeHubsā that are supplied by a few related ISPs here in the UK and they would be fine and work perfectly UNTIL the point where network traffic reached a tipping point and then theyād start dropping UDP traffic on the WiFi network and would continue to do that until they were rebooted ā¦ unfortunately itās impossible for āusā to do anything to fix things like that.
Unfortunately the reply we often get is āBut my computer and phone are working fine so it must be your problemā and that isnāt necessarily the case - for example, if the computer and phone are using TCP when itās UDP thatās being messed up by a piece of network hardware then the PC and phone will work fine but - say - autodiscovery in a streaming device app will fail because the UDP / UPnP discovery will fail.
One thing that is definitely worth noting is that people often donāt help themselves by using Ethernet cables that are shielded and have shielded Ethernet connectors that directly connect the chassis ground of your audio streamer to the chassis ground of what might be a quite electrically noisy networking device. There really is no need to be using a firehose thick CAT27j Ethernet cable (no, there isnāt a Cat27j) that can handle 200Gbits/sec of bandwidth when even UNCOMPRESSED 24bit/192kHz stereo audio can be handled (OK, only just with overheads) by 10mbit Ethernet which was superseded 30 years ago. 100meg Ethernet is an order of bandwidth more than is needed for 24/192 and Gig Ethernet is another order of bandwidth more than needed again.
Also, be aware that heavy and stiff Ethernet cables (especially when they are also using lovely looking big metal Ethernet plugs) can put a huge amount of strain on PCB mounted Ethernet jacks and over the years I have seen Ethernet ports leveraged away from boards because of the strain applied by such cables and connectors - a simple decent, certified, Cat5e or Cat6a unshielded Ethernet cable will prevent chassis noise being transferred from a downstream device into your streamer.
I also get that fibre is being used to electrically isolate audio devices from the rest of a network using inline Ethernet to fibre transceivers but remember that those CAN also generate their own electrical noise themselves so just be aware of that and the above notes on Ethernet cables still apply for those being run between an audio device and an Ethernet media transceiver if you go down that routeā¦
BR
Phil