At the application level, TCP network data, which is what it is (not audio) will (simplistically) behave as follows:

Sooloos sends audio data as PCM packets over TCP protocol. These packets will be received by the audio endpoint thus:

1. It will be received 100% correctly.
2. It will be received 100% correctly, but may be truncated. Subsequent reads will read the remainder of the data as per these rules. Truncation is entirely normal operation and may be caused by a number of things, such as exceeding MTU size in network equipment.
3. The data may not arrive.

It is impossible for an application to receive data that is 99% correct. Its either 100% correct, or nothing. Bits is bits at the application level of networking.

In #3 above, the effect is 'catastrophic' and will be clearly audible. I use the term 'catastrophic' to mean that it is an error that the application has to act upon to resolve rather than something like a thermo nuclear meltdown.
In #2 above, truncation is normal expected behaviour for long packets, which the PCM packets will be. It is possible that there is a bug which does not reassemble truncated packets correctly. I can see that this could have a subtle audible effect.
In #1, #2 above, the application will have received the data 100% correctly, but at lower layers (OSI 7 Layer Model), things may be quite different and things like error correction, retransmission, packet reordering may have come into play. But this is all transparent to the application and in the end, the application will receive 100% correct data, or nothing. There is no reason why a wired home single subnet network should not be 100% reliable 100% of the time, thus if error correction etc comes into play, then there is a network issue somewhere. Note that I also say wired home network. Wireless and powerline networks work quite differently and retransmission, error correction etc may occur on a frequent basis.

What we cannot see with Sooloos (sorry Meridian but Sooloos has kind of stuck) is the effects of non optimal network. Can we hear the effects?

When data is waiting to be received, the wait is often subject to a time out - I don't know whether Sooloos is or not. If the timeout occurs, then it is a catastrophic failure and the application has to resolve the problem. This is unlikely to be inaudible.

If data is received late, but there is no timeout, then receipt of the data may fall outside an acceptable timing window that the Sooloos audio endpoint can handle - possible with non wired networks. We also know that jitter affects audio. However, we are talking about a network packet here, typically holding 1500-4000 samples, not just a single sample. I believe that if the packet is received significantly late, then the result will be clearly audible as an audio glitch. For slightly late packets, bearing in mind that it is travelling over a general purpose network which will have other network traffic, I believe that at most, the samples at the packet start (and maybe end) may be subtly audible, but only for a few samples and entirely randomly. I don't buy this bass is better stuff, its going to be everything.

What if there is a bug in the software or hardware, or in network equipment? Well, it is conceivable that the application will receive network data that is not 100% correct but is told otherwise. I do not believe that this is an issue as it would appear that Sooloos uses much standard equipment and software (Busybox etc) and bugs such as this would have manifested itself in many other ways. It is possible that Meridian have written their own network stack, but I suspect it will have been based on a port from existing code. Finally, this is easy to test and I would like to think that network transmission has been tested independently of audio.

Can something else be at play? Well, I don't understand about emf, rfi, cables, ferrite cores, shielding and things but there was a pretty good thread that made me believe that this can all have a difference. But not at the MD600 end.

So, my 2p's worth.

I don't buy the moving NAS boxes, or putting them on feet stuff. They are totally decoupled from the audio endpoint (ensemble and MC200 excepted) and I just cannot see anything that can have an effect, short of introducing problems (bending a cable too much etc) into the 100% reliable 100% of the time network which may or may result in something randomly audible. Busted or go fix your network.

I don't buy into the one router/switch sounds better than another. If you stick with a switch, you get network speed access between ports - remember that it looks like audio endpoints are limited to 100mbs connections anyhow. If you go for a router, you should be using it as a switch if you connect it to the row of RJ45's on the rear, but if you aren't, say connecting to wan port, or you have an oddball switch that routes some of the ports, then you will get non network speed access as the packets are being routed at slower speed which may cause problems. The latter applies to some routers with wireless access points, where the wireless LAN may be routed. That said, Sooloos network requirements for audio are quite small. Busted on a wired network, plausible on a network with errors or on those that transmit audio over wifi or power line adaptors.

Can the design of the audio endpoint and cables feeding it have an effect. Plausible.

Can there be a software/hardware fault in Sooloos making it not behave optimally under non 100% conditions. Plausible but I doubt it as the issues would be far reaching and not just subtly audible.

Can there be a 'special sauce' in the core that makes one behave slightly differently to another. Meridian say this is busted.

Meridian owner since 1992
Prime & PSU, Focal Elear headphones, Roon (ROCK 8Gi5 NUC), Explorer 1 & 2, F80. 200/203, various Sonos (via Roon).