In the current implementation of speaker.playAudio, the server keeps track of where it things client playback is up to. Once the client's buffer is running low (<0.5s), we send the next audio packet. On the client side, we then add the audio data to the queue.

However, this requires the server to make several assumptions about the client's audio playback, which don't always hold. For instance, if the speaker sound does not play immediately (e.g. by setting the volume to 0 (#2108), or having too many speaker (#1313)), then the client-side audio buffer will continue to back-up. When the speaker finally plays, it'll start from the beginning of its queue, rather than the server's current position.

I'm not sure what the right solution is here. I think the best option is to attach a timestamp to each audio packet (normalised to the start of the audio stream), and have some client-side handling to either pad/drop packets in order to fit to it.

#1874 might be worth investigating at the same time (ughr, I did look into this, and then didn't write anything up, so will have to do that again!). I don't believe the audio desyncs mentioned in #1488 are related.