joerg-krause writes

Would it be possible to do the syncing using timestamps? If yes or maybe, what would be necessary?

medoc92 writes

I’m not exactly sure what we are talking about here, but if you think of the sync of the audio streams in multiroom, this is handled by the Songcast protocol and its implementation in the openhome libs. The idea is that the Sender defines the master clock and that the Receivers must adapt to it, which, in the case of sc2mpd is done by sample rate conversion (controlling the size of the audio driver input queue).

One thing missing in the current code would be a way to configure the size of the queue, to allow synchronisation between different hardware devices which may have different internal delays. This should not be too hard to do, but nobody ever asked for it.

joerg-krause writes

Sorry that I was not clear enough!

> The idea is that the Sender defines the master clock and that the Receivers must adapt to it, which, in the case of sc2mpd is done by sample rate conversion (controlling the size of the audio driver input queue).

I understand that the Sender defines the master clock and that the Receivers must adapt to it. I’m afraid I do not understand (yet) how the sample rate conversion factor is actually calculated. To be honest, I haven’t really tried hard enough.

I know, that shairport-sync uses timestamps to synchronize with the AirPlay sender. However, it does not use sample rate conversion. So, my question should have been: why is sample rate conversion necessary for Songcast and if it could be avoided.

The reason for my question is that sample rate conversion is expansive on my soft-float devices.

medoc92 writes

I understand, and cpu load on the small end devices this may be a reason why Roon does the reverse: the server adapts the sample rate to each receiver.

Apart from distributing a hardware clock, there are not a wide variety of solutions, there are exactly three as far as I can see:

  • You can adapt the harwdware clock on the DAC to the data rate. That’s what Linn does. I wonder that nobody is up in arms about the phase noise… Whatever.

  • You can convert the sample rate. I am not able to do the maths, but I tend to believe that this is quite equivalent to tweaking the DAC clock.

  • You can drop/pad samples. This unavoidably causes drops, clicks or other artefacts, but if the Sender and Receiver clocks are very close, the problems will occur rarely, and this is actually the most accoustically transparent solution (between the clicks :)).

sc2mpd adapts the sample conversion rate by controlling the driver input queue depth. If the queue lengthens, the rate is lowered, if it shortens, the rate is increased. In practise, the conversion rate stabilizes quite quickly, but if there are network issues this can become comically audible.

Multiroom is definitely not for audiophiles.

joerg-krause writes

Yes, because of the cpu load I am getting constantly disconnections.

I know that shairport-sync does drop/pad samples. This works really well on my device. It is possible to add this behavior to the songcast receiver?

medoc92 writes

When using SRC_SINC_FASTEST, I think that the CPU load mostly comes from conversion to float and back. This is a bit stupid because it’s of course not really needed, but I don’t think that libsamplerate has an option to work with ints.

So this is a significant development, to allow bypassing libsamplerate completely and drop/pad samples as needed by the queue state instead.

joerg-krause writes

You’re right, libsamplerate has no integer option.

> So this is a significant development, to allow bypassing libsamplerate completely and drop/pad samples as needed by the queue state instead.

I will try to understand the code. Maybe, I’ll give it a try.

medoc92 writes

It would not be complicated to make an int version of libsamplerate (in zero-order-hold mode). There are just a handful of lines to change. But doing this would still need copying buffers around, which may still be more cpu-intensive than tweaking the driver input queue.

joerg-krause writes

Yeah, most probably that would be the case.