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