Drifting metronome

[kousu]

I gave SonoBus a shot today and it was pretty great! The quality right out of the box was really great, even though we had latency issues with latency around 110ms; my partner will probably need to go shopping for a professional DAC to fix those.

In the meantime, we discovered the metronome feature and tried to use that to sync ourselves up. However we noticed that the metronome was changing speed! It seems that the metronome is affected by latency too?

Here is a sample session I recorded showing the problem. This had the metronome set to 76 BPM (=> 0.789s/beat), with the metronome being broadcast from my partner (who was having high latency):

SonoBusSession_drifting-metronome.flac.zip

I generated a click-track using Audacity to compare what I heard from what I should have heard:

SonoBusSession_drifting-metronome_with-reference-76-bpm.flac.zip

I made sure to line up the first beats:

however, with those aligned, the latter beats are misaligned:

and you can hear the trainwreck sound if you listen to the second flac.

---

It would be cool if the metronome was sent as metadata instead of as sound. Each SonoBus should be able to take care of generating its own sound and syncing it with the stream. That would give a more reliable metronome for everyone to follow along with!

[Zipdox]

Sending the metronome as metadata does not fix the latency problem. You can try to mitigate drift by setting the jitter buffer to a fixed value.

[kousu]

I'm sorry but I don't understand. Can't you use one of these?

• https://en.wikipedia.org/wiki/Network_Time_Protocol#Clock_synchronization_algorithm
• https://en.wikipedia.org/wiki/Cristian%27s_algorithm
• https://en.wikipedia.org/wiki/Berkeley_algorithm

Then you can send metadata like "metronome starts at 93.3423s after T=0, at frequency 132BPM", relative to the syncronized

Or, instead of implementing complete clock sync, you could trust the system clock, but still send the same basic metadata, like "metronome starts at 19:23:07.0204s, at frequency 132BPM"

Or split the difference: measure clock drift but instead of correcting for it, warn users that they need to check their system's NTP if it drifts too far, and send the same metadata. NTP is pretty solid these days.

[Zipdox]

Oh in that sense. You want the metronome to run individually on both clients. That's an interesting proposal.