This is audio not rocket science. Even 24/192 is minimal data and and any number of bit perfect options exist. Wireless networks are more than sufficient to carry audio error free with retry. Again not rocket science. Data rates are way faster than needed to recover lost packets without breaks.
Your posts are conjecture, no more.
Respectfully, it seems to me that your post is coming from an arena of conjecture and lack of comprehension.
The question I was replying to was with specific regard to Roon. Roon uses an architecture that relies heavily on a robust network and anyone investing $500 in Roon software to manage their music library should consider the small investment to get the necessary infrastructure to hardwire their endpoint and Roon Core to the same network switch.
While from a pure data perspective you are not wrong, you are ignoring a bunch of factors, including the delivery protocols which are used to stream audio on the network in the first place, not to mention the inherent challenges of WiFi.
If a server (Roon Core in this case) is delivering real-time audio data over the network, it is using some method of UDP encapsulation (which they term RAAT) to send the audio to the endpoint. UDP can and does experience dropouts if sufficient attention is not paid to how the network is configured as well as what other devices may also be using the same datagram protocols on the network.
The above paragraph applies to a wired network. Wireless adds the complexity of an air-based physical medium (instead of a copper or fiber connector between the networked devices) which is prone to interference, signal loss, noise, improperly set timing thresholds, improperly configured channel bands, additional latency problems, etc.
Further, depending on the chipset in the device(s), WiFi can be limited to half-duplex transmission, meaning it can require twice as much network and processing resources to perform checksums of the packet data. This is less of an issue with 5GHz A/C bands and MIMO capable WiFi access points these days, but unless you are aware of what chipset your audio/streamer manufacturer is using for their WiFi implementation, it's certainly possible to still run into this limitation.
For someone with a single Roon (or other network endpoint) with an off-the shelf Asus/Netgear/TP Link router, WiFi should be fine for the endpoint, but the Core should still be hardwired.
Things get complicated really quick as soon as you add more wireless devices to the network, especially if they are competing for the same resources on the network.
Also, WiFi chipsets inside network streamers can add unwanted noise, depending on who designed the thing.
I had to laugh at your comment because I've fixed so many problems for people by switching them from a consumer-based WiFi connection for their audio streamer/endpoint to a hardwired connection because they were experiencing dropouts, and had many satisfied listeners. It's simply less hassle if you can hardwire when you can.
WiFi should be used for tablets, laptops, phones, etc. Permanently located, non-mobile devices with an ethernet connection should be hardwired whenever possible. It's best practice type stuff.
