[sc-users] Re: Syncing clocks over the network

[jamshark70@xxxxxxxxx]

Finally able to close the loop on this topic.

Nathan:
> the incomplete ableton link branch is your best bet. link developers have put a lot of work into this problem (peep the source: all kinds of fancy stuff like kalman filters and linear regression) and their solution is bound to be more reliable than some sclang jury rig.

I finally had a chance to try it. It looks like, in its present state,
it will already work very well for syncing a number of SC clients.

At the moment, I'm not able to test SC <--> Ableton or SC <--> any
other Link-enabled software. I don't believe that will work in its
present state. Ableton says it's the client software's responsibility
to report to Link the time when the sound will hit the speakers. As
far as I can see, we are reporting the sclang clock time and *not*
accounting for OSC timestamp latency.

BUT... unfortunately, I probably can't use it in class because the
media lab is stuck on an older version of MacOS, so I can't update SC
past 3.9 in there. That creates a whole slew of problems for me, but I
have to work with what I've got.

Scott W.:
> BeaconClock in Utopia

I had reported that this worked well, in advance of my workshop.
Unfortunately, in the workshop, with 6-7 peers, there was always at
least one machine about 1/3 to 1/2 a beat out of sync. I don't know
how to resolve that problem.

So... can't use Link, don't trust BeaconClock... but this week, I had
a brainstorm about taking some of the approach from BeaconClock and
adapting it to a simpler, master-slave approach.

Scott C.:
> I spent easily 3 or 4 days in 2008 trying to figure out a clock sync solution using NTP, OSC messages, everything I could think of.

I don't know about 2008, but I'm sure that now, if the incoming bundle
has a timestamp, you get the actual timestamp. This means, if my
"master" sends consistently-incrementing timestamps, the "slaves" can
rely on the timestamps to be accurate.

Without NTP, `SystemClock.seconds` here will be different from
`SystemClock.seconds` there. But the slave can measure the difference
(taking the median of several samples), and use that to convert the
timestamp from the other machine into a SystemClock.seconds to
schedule on the local machine (and we can trust that this timestamp is
increasing consistently). I found empirically that network jitter is
usually well below 1 ms. The median filter likely reduces the error to
an order of magnitude smaller than 1 ms, undetectable to the ear.

From BeaconClock, I learned that you can set a TempoClock's 'beats'
directly. If the adjustment is small, it's undetectable but enough to
maintain sync. Also, I like BeaconClock's technique of randomizing the
interval between sync messages (to avoid high-contention integer
beats).

So...

Quarks.install("https://github.com/jamshark70/ddwOSCSyncClocks.git";);

// over there
TempoClock.default = DDWMasterClock(2);

// here
TempoClock.default = DDWSlaveClock.new;

I'm still testing, but it's promising so far, and it doesn't require
any new backend code.

Would be delighted if others could test it too.

hjh

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/