What do you consider a good sync?

[CarlosDerSeher]

I have been fiddling around with syncing algorithm a lot but found that I can't do much better than around +-2ms. Sometimes it's perfectly synced, but then it drifts apart again, but mostly stays within +-2ms margin. This is also the case if I use two raspberry PI or put an ubuntu notebook client into the picture. If comparing two different hardware platforms against each other the deviation gets even "worse" up to 10ms or so, but that's to be expected I guess. So comparing two esp32 clients I get around +-2ms which also depends on which platform the server is running.

While doing some research I read that for multi room systems such offset of clients is good enough and I feel the same way when using the system at home.

But now I was thinking about using two clients to make a stereo system. I read client offset should be in the µs range. Is that really the case and what's considered a good sync in both cases?

[luar123]

Just some thoughts, without much background knowledge on my side:
Speed of sound is 343m/s at room temperature, so 1ms delay seems as if one speaker is 35cm farther away than the other. That explains why 10ms is good enough for multi room where you typically have a big distance between speakers + walls and speakers pointing in different directions.
For stereo I guess it depends on the use case. For background music where I am in a random spot in the room I think 2ms should be good enough, maybe even 10ms. However, if I really wanted to listen to some high-quality music, sitting exactly in the center of the speakers (or using headphones) the µs range is probably needed.

[CarlosDerSeher]

So I am thinking... there are systems which can do it. How for instance does Sonos do it? Is snapcast even fit for the task or do we need some specialized hardware to accomplish such precise syncing. There are time sync protocols out there which definitely can do it but you'll need hardware capable of doing it. Maybe an esp32 with a more precise clock source would be needed to stop them drifting too much around? I guess the modules have a clock with a maximum precision of 10ppm maybe even worse? Still that should be manageable as we can scale the apll as needed.
I am a little lost here because badaix states

Typically the deviation is below 0.2ms

And I can't achieve these numbers. Most of the time it's much more even when using his original code on much more capable machines.

I probably have to do a wired test and see how it goes there.

[CarlosDerSeher]

@luar123 alright I think I got it now! changed some parts regarding latency measurement and time sync message sending. Also changed task priorities and pinned to core 1 and now the sync stays below +-500µs, often even below 200µs for quite a long time. I am very pleased with these results :))
Maybe you'll have time to test during the holidays, merry Christmas to you :)

[luar123]

@CarlosDerSeher That's interesting, using the metronome with snapcast I don't get a uniform signal at all. The server detects silence between the clicks and toggles the stream between playing and idle. Leads to a lot of hard re-syncs on the esp client and some other warnings on a linux client. Adding some noise works, and with this I can confirm a sync below 500µs between an esp and a linux client. Could be even better, but my dac is quite noisy so the exact start of the click is hard to see. I guess it is a good idea to use exactly the same hardware, to get rid of any differences in the audio chain if you need a very accurate sync.

[CarlosDerSeher]

@luar123 great but also strange. Do you have the newest snapserver installed? How do you provide the metronome signal? I got a bluetooth dongle which uses blue-alsa in combination with the alsa write file plugin to put samples into /tmp/snapfifo which works without any problems like that.
Also I am interested in your test setup, server machine and mesurement device. Do you use a scope too? As written earlier I think it would be a good method to use a 2 channel mono to stereo cable and connect that to a soundcard to record a long duration of audio for comparision. Also the two esp clients are placed right next to each other on my table, I don't think it will make much of a difference, but testing them farther away, maybe one in a worse reception spot would be interesting too.

I guess it is a good idea to use exactly the same hardware, to get rid of any differences in the audio chain if you need a very accurate sync.

If you want to have the most exact sync I am sure you must use exactly the same hardware. Though the used DAC shouldn't make much of a difference when using the esp client. Also I am pretty sure that using the esp client, you'll get the best syncing results of all because you are so close to the hardware and don't have an operating system in the way.

[luar123]

I am streaming to the snapserver with rtp+aplay+alsa loop device or with dlna (gmediarenderer) + alsa loop device. Have not tested to play it locally over mpd+snapfifo file. So maybe that's a difference.
My server is a x86 linux machine with latest snapserver and snapclient. Audio over alsa and mainboard soundcard. Other clients are raspis, one over Ethernet, one WiFi, but I have not measured those yet. Measuring is done on a scope comparing esp to the client on the server machine. I will run some more test when I have time, but for now sync is good enough for me :-)

[CarlosDerSeher]

So probably snapserver's alsa source thinks it gets silence from also loopback device and closes it. You could also use a faster metronome to overcome that i guess.
Thanks for all your input.

[CarlosDerSeher]

@majoreffort oh and great to read there even more people into this project. Next step will be to implement the other codecs I guess.