@Rik, @Bitperfect in both cases of Airplay and Songcast, the sender sends packets to the receiver at a constant rate, based on the clock inside the sender. The receiver reads these packets, and plays them using the clock inside the device. You’d think this was perfect quality, but let’s do a simple thought experiment:
Let’s say your Mac’s clock is 10% faster than your DAC’s clock. Then, whether it is Roon, iTunes, or whoever, sending CD quality data over Airplay or Songcast will send 48510 (10% extra) samples every second instead of 44100.
There’s no way in these protocols for the receiver to say “slow down! you’re sending data too fast”, so the receiver has to deal with this situation somehow. It could drop the extra 4410 samples, creating one big glitch, or perhaps many small glitches over the course of a second. It could perform an Asynchronous Sample Rate Conversion (ASRC) in software or hardware, taking a quality hit in the process, or it could bend its internal clock to match the clock of the source. Clock bending is the highest quality option of the above, but it doesn’t stop the music from playing 10% too fast.
This is what we mean by the clock being owned by the source in these protocols.
@Rik, In the case of your Linn devices in a linked situation, the clock is owned by the DS, but that’s because you are still using UPnP instead of Songcast to get media into the Linn DS. If you used Songcast, you’d be at the mercy of the source’s clock. Also, if the clock in your Sneaky DS’s deviate from the master clock in the DS, it’ll have the same problem of having to conform to the master clock. This is a fundamental problem when linking zones in any system, since no two clocks will ever be in perfect sync. In this situation, bending the secondary clocks is the best option.
So in a purely Linn hardware driven environment, where the stream is driven by a high quality clock that you trust, there is little quality concern. That’s not the situation when source like Roon, iTunes, or the Linn Songcast audio driver interact with a protocol like Songcast or AirPlay, since in those cases, a computer is clocking out the stream. Since there’s no way in the Songcast protocol to recover the high quality clock from your master device, the computer’s system clock is used, and all Linn devices must compensate for any deviations from perfect using one of the techniques mentioned above.
The right solution here is to allow the sender to synchronize it’s sending to the receiver’s clock. This can be done through clock feedback from receiver to sender, or it can be done via many different flow control mechanisms. RAAT does this.
You can read about the Songcast protocol here: http://wiki.openhome.org/wiki/Av:Developer:Songcast:Ohm
Airplay doesn’t have an official published protocol spec, but you can read about a reverse engineered spec here: http://nto.github.io/AirPlay.html