Question about sync method

[erkkah]

Hi there.

While working on a go client library implementation, I realised that I do not get how the Snapcast sync method will work in the general case.

I do understand the time sync method and protocol, but looking at a higher level - how can the system make all clients play in sync when it is only up to clients to speed up / slow down to get in sync?

Let's say we have two clients, A and B.
Client A has 200ms throughput latency (from received chunk to speaker output) and client B has 10ms.
Since the server does not do any inter-client delay compensation, how could these clients ever play in sync?

I get that the players can keep in sync at a somewhat fixed delay. In my example, A and B would not drift apart more than the 190ms between them. But if the server is not delaying the stream to B, the players will not be in sync.

I hope I'm missing something important here :)

[badaix]

Hi,

every audio chunk is tagged with the local server time. The default buffer size is one second and so each client must play this chunk at the tagged time + 1s. To be able to do this, each client must know the server's local time. Therefore a client sends his current time in a TimeMessage to the server and the server will send a 'TimeMessageas response with his current time. Knowing both times and the round trip time of this message, the client can calculate the time difference to the server and hence knows the server time (local client time + difference). You can find a quite compact implementation in [Snapweb's snapstream.ts](https://github.com/badaix/snapweb/blob/master/page/snapstream.ts).syncTime` is called every second (line 963) and the time difference is calculated in line 943.
For fine tuning you should also consider the latency of your DSP, which is reported by lower level APIs and heavily depends on your audio buffer strategy (number of buffers + size).

[erkkah]

Hi.

Thanks for the fast response and explanation!
The part that I did not understand was that the server buffers all chunks and that makes it possible for clients to read from any relative position within that buffer by speeding up and down, or throwing away chunks and waiting.

So a hypothetical client with zero latency would always read from the "end" of the buffer, getting maximally delayed chunks, and the maximum total latency allowed equals the server buffer length.