How tight is the time sync

[StuartIanNaylor]

On multiple devices whats the time sync tolerance of squeezelite-esp32?

Or should I ask does it?

[sle118]

Not sure I understand what you mean by tolerance?

The sync mechanism is required when some devices process samples/play slower than others. In an ideal world, all clocks would have the same frequency and samples would be fed at the same rate to the DAC. This is not the case, however, even for devices from the "same batch of components". Each device has a clock that has a small drift that cause samples to be consumed at more or less the same rate, with variations that aren't noticeable.

In short, each device sends a status message back to the server that includes the current sample position and a time stamp. The server then sends "skip X samples" back to players that are lagging beyond a certain threshold. There's a bit more to it than this, but it should help you get the point.

This means devices from Logitech should play along fine, synchronized with ESP32 based devices. Someone from Logitech said that in the early days, they tested successfully with "a large number of players piled on top of each other".

You should pay attention to the network bandwidth, though, as it has been the bottleneck for several users. This is important if you either live in a larger home where wifi signal needs to travel through walls, as signal strength might become an issue. It is also important if you live in a building with lots of access points and users since your devices will be competing with others for a given wifi channel bandwidth.

Let me know if this helps

[StuartIanNaylor]

I wasn't name dropping but will do as it will make more sense. I was looking at squeezelite vs snapcast (pi) for distributed active mono amp speakers.
Its the network side of jitter and load that seemed to be much of what snapcast was about that seemed to be lacking in squeezelite but what you say sounds similar but could not really find much info about it.
I had 2x PiZ2 anyway so snapcast it is but just been looking a HomeAssistant and thinking I could of gone squeezelite-esp32?
Snapcast apparently manages to keep this pretty constant to approx a max of 1ms.

PS with memory concerns this is the 1st clone I have seen for $7 as seems the snapcast-esp is a big struggle also and not that active but would love a really robust esp version that has the space for those big buffers, its 2mb but maybe more will come.
https://www.cnx-software.com/2022/07/08/banana-pi-bpi-leaf-s3-esp32-s3-board/ but could be 32mb is one existed.
Do you think a 8mb port might be of interest? Plus the math vector optimisation's are up x10 faster on the S3 and would be more likely to dump the Pi's.
I have a ESP32-S3-WROOM-2 – 32MB Flash 8MB PSRAM if you want it as a donation :) but maybe bung a donation button on the git hub as have been known to from time to time :)

[Joshfindit]

@StuartIanNaylor If I understand correctly, the core of your question is:

When playing multi-room audio, what's the maximum that one device's output could be out of sync with the others: <1ms, 10ms-30ms, >30ms?

Is that right?

[StuartIanNaylor]

Yeah is there any control where on different carriers such as wifi, ethernet and infrastructure routing, is there anything that resyncs on NTP or other methods?
And what is the tolerance of the resync <1ms, 10ms-30ms, >30ms?

[philippe44]

There is no use of NTP or such with, LMS whose target is 10 ms for resync which as you know gives you 3m which is fine with me for multiroom because, by definition you're likely to be more than 3m away from ideal position. When using AirPlay, it's using NTP-type sync timestamps.

[sle118]

Il go ahead and convert this to a discussion

[StuartIanNaylor]

How does it resync as for me its not about multi room but multi speaker with active distributed channels.

This is complete presumption as just always presumed NTP was used to sync the clients and then on receipt of timestamps the mismatch would jog +/_ the buffer to correct on each client?

[philippe44]

The LMS sync is very simple but just works for its objective: the server sends a message with its own time tick and request each player to respond with its local time tick when it has received it. Do that a few times and you can remove the RTT. Then you can control when players start and afterward see if there is drift in the pairs of time ticks.

I'm always amused to see that the audio world seems to do many overdesign and build some insanely complicated system where they have very simple issues to deal with. I'm a properly educated engineer in digital signal processing for the telecom (RF) industry. Everybody wants more bits/Hertz and of course without using power, all that in very nasty propagation channels - that's really a serious set of challenges. I'm not trying to be contemptuous and I know that some other domains are way more complicated. It's just the audio industry being surprising good at creating complex solution in search for a problem.

[philippe44]

No no, it's not NTP at all, just a local clock and there is no clock synchronization. NTP refers to a very specific protocol which is not involved here.

[sle118]

I'm guessing the server's role is to keep track of individual players drifts and the fact that you can fine tune network latency in LMS means that every player out there can send it's status using the time provided by the server and assume "real time", or a time gap that's probably less than the distance between speakers in a typical setup?

[StuartIanNaylor]

Maybe and apols for the namedrop but snapcast does something very similar as it embeds a timestamp so the client can jog the stream to a point in the buffer to its local time difference.
It does need NTP to sync the remote clients so they job the play buffer so all the clients are in sync coordinated by the embedded timestamp from the server.
I can not see anywhere where the client does roundtrip latency calc so it knows how much that client needs a jog offset.

[philippe44]

The client does nothing in LMS except reporting its time (jiffies) most of the time when it responds to a server request. The server does the round trip estimation and all the alignment calculations. Then, its sends a request for "skip N ms" or "pause for N ms" to the client which does just that.

[StuartIanNaylor]

Its prob no good anyway as 10ms/3.43m for active mono speakers is tending to creep a bit large, fine for different rooms of a single client multi channel output but prob not too great for multi client single outputs in a room.

I think Snapcast can manage 1ms accuracy (supposedly 0.2ms 48khz) but the esspressif NTP is fairly junky in terms of precision but someone has wrote a high precision ntp lib to 1ms.
[edit] my memory is really bad but if 48khz it can correct to sample so max accuracy of correction is 0.2ms but there are only esp32 libs avail of approx 1ms ntp accuracy but linux on a local lan can achieve better but 1ms is prob a good datum.
Also I would say its actually more simple as it contracts out sync to NTP and then just embeds a timestamp to already synced via ntp clients to then jog a buffer to correct on the received timestamp.
Reading further it maybe be similar to squeezelite just far more accurate and not use client ntp, I misread brief reading an article but local ntp can cause problems so can not be.
Its the 'feathering in' of the latency compensation that is more complex as sqeezelite doesn't.

I have a hunch some of the fancy non linear AEC silicon could take a ref signal from squeezelite to apply to a mic array and was wondering with a strong fingers crossed if the tail from the ADF AEC could maybe use it and still be effective if you record back on a hardware loopback (spare channel).
I actually doubted it was implemented in squeezelite as just could not find the code, 10ms is prob too large anyway. Also snapcast 'feathers' sample duplication/removal into the buffer and that was what I was looking for as squeezelite seems to just hard reset the offset with a skip & pause.

Thx for you time as I have read about the multiroom sync of groups but could never find how, what and to what resolution.
I think my slow mind has now absorbed what I need and now even more confused as does not the hard reset of squeezelite pause/skip not cause audio artifacts?
I presume it must and the networks it commonly runs on are pretty consistent in that 10ms latency difference as without sample feathering we would hear it or at least non audiophile ears don't.
I like squeezlite as you have managed to get it run on esp32 but really hard resets of pause/skip is not what I thought of as latency compensation as its purely latency correction with possible audio artefacts, 10ms/3.43m is pretty huge though.
That large deviation makes Sonos like individual active speakers a no but for feeding multichannel amp or hardware loopback for an AEC it can still do.
Snapcast blends in its latency compensation to a much finer resolution and if on arm then think is superior, but the feathering with AEC could actually be a negative, if it is accurate to 0.2ms/.07m then that is really negligible for distributed active speakers in a room. You just can not buy a Pi at moment and even a PiZ2W is 2-3x a Esp32 devkit
I am thinking I should hold out and see if I can work out BLE 5.2 Auracast as very early days but that could be a better solution, things are never simple are they, purely as eventually that could fill all roles and be low cost :).