Hi

I have undertaken a handful of tests and not seen situations where audio portions of the stream are not identical between multiple runs.

However this is between an MC200 and Control:Mac as I do not have any other Sooloos equipment. My tests also were on an audio track truncated manually to approximate 40 second track - I think a perfectly valid amount of time for people to hear differences. There is potentially a huge amount of data that can be generated and keeping this to reasonable quantity that can be fully verified is IMHO more valuable than looking for a needle in a haystack.

I put together a (relatively) simple test to prove whether or not Sooloos audio passing over the network is consistent across multiple identical runs. Some people are reporting hearing differences due to changes in their Sooloos setup. I wanted to create a test to prove whether these differences were data related or not.

There are other better tests that could be performed, but I wanted a test that was suitable for as wider range of audience as possible using a basic network setup. This test is analogous to an A/B listening test, except that proof of differences (if any) can be verified analytically.

The test as presented does however rely on a number of basic, but I believe valid, assumptions. The most important is that undesirable differences will be random and this can be shown as differences between multiple runs. A random difference indicates a likelihood that something is not right (with the network or Sooloos equipment for example) rather than a change by design which would likely be repeatable across consecutive runs.

Another assumption is that to achieve consistent results across multiple runs, the network should be robust and 100% error free. A hardwired home network should IMHO be 100% error free. Add wireless or power line and all bets are off as these are highly dependant on environment conditions.

Wireshark is capable of testing the validity of both of these assumptions but this test does not make full use of Wiresharks ability to help resolve issues, merely to identify whether one exists or not. The Wireshark statistics/compare function allows you to take two files captured from different ends of a network that have been merged and analyse them for dropped or mis timed packets amongst other tests, but this requires the ability to simultaneously sniff two network ports at different network locations. Wireshark does allow packets with errors to be easily detected - these are highlighted in red on the main display (I believe by default) so it is very easy to spot packets that have errors detected with them. Unfortunately the type of error checking used in IP network packets is not 100% reliable in some circumstances so a very very small percentage of errors may not get reported but I believe that the chances of this happening on the same packet across multiple runs is tiny compared to consistent differences that may be heard by someone noticeable audio differences in a listening test.

At the end of the day, I would expect multiple runs to be 100% consistent if used in a hardwired network, except in the IP and UDP headers and what appears to be a byte (or two?) immediately following the Sooloos AESPDATA. The IP differences are to do with sequential ID and header checksum and UDP destination port (only in packet containing Sooloos AESPDATA).


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