[80c] time

Sam Birkhead sambiotic at gmail.com
Fri Apr 13 15:47:27 CEST 2012


How about;

Calculating the relative CPU clock offsets with pings, asking what time
each peer thinks it is now. Doing some statistical analysis on multiple
results for accuracy.

Then after startup and under normal operation have a forwarding deamon
present each peer unicast with a time tagged bundle relative to the target
peers CPU clock for future execution.

Future synchronisation removes jitter at cost of fixed latency.

This should result in synchronous events on all peers removing the reliance
on ptpd.

Thoughts?
On Apr 12, 2012 1:28 PM, "alex" <alex at slab.org> wrote:

> Hi all,
>
> I think Sam's mail below just went to me when it was supposed to go to
> the whole list.
>
> I've started thinking about time sync again.  I'd like to do without
> ptpd as it appears to be patent encumbered and so likely to disappear
> from Debian at some point, plus there are various versions which don't
> appear to work well together, and so on.
>
> So I propose:
> - a standalone time sync protocol based on OSC over multicast ip
> - featuring automatic nomination of a clock server, where when a clock
> server goes offline another client takes over
> - a measure of clock offset based on sntp (simple network time
> protocol) or this:
> http://www.mine-control.com/zack/timesync/timesync.html  -- good
> enough for reliable LANs
> - share bpm scheduled changes
> - don't bother updating system clocks
>
> I'm planning on writing this as a C library using liblo.
>
> I was thinking of using xmpp or http (rest) but probably easiest to
> stick with good old OSC.
>
> Does this sound reasonable?  Anyone want to help?
>
> cheers,
>
> alex
>
> On 15 February 2012 17:35, Sam Birkhead <sambiotic at gmail.com> wrote:
> > Hi all. Julian pointed me in the direction of this list. Looks like
> > interesting conversation with like minded people. Glad to be here.
> >
> > The idea with zosc was to separate control and audio as usual but
> schedule
> > everything.
> >
> > Osc control events are broadcast and scheduled for future execution, both
> > locally and on peers for a fixed time offset greater than one way network
> > latency, then executed synchronously. This eliminates network jitter at
> the
> > cost of fixed latency. I'm using 15-30ms but depends on number of peers,
> > network design etc.
> >
> > This does mean things like sending analysis of synchronously generated
> audio
> > as control over the network is intrinsically difficult as you're behind
> > control time and yes, requires system clocks in sync as Alex mentioned.
> >
> > With regard to how accurate a system like this needs to be, I'd argue
> only
> > with the realms of a few ms. Just so there is no flam effect on audible
> > events. For example in tests, I could measure but not hear localhost udp
> > latencies, so I dont account for or worry about them. This also means I
> can
> > sync up software that is osc, but not osc time tag aware.
> >
> > Hooking up with live performers is another interesting challenge. Trained
> > musicians can start together, when conducted very precisely. A conductor
> > paradigm, physical or otherwise would be worth investigation.
> >
> > Sam.
> >
> > On Feb 15, 2012 1:14 PM, "alex" <alex at slab.org> wrote:
> >>
> >> On 15 February 2012 12:51, Aymeric Mansoux <am-80c at kuri.mu> wrote:
> >> > How would you go about that? What would be the departure point?
> Listing
> >> > the flaws of existing solutions? Building up on top of existing
> >> > technology or come up with a new one? Start from scratch figuring out
> >> > the needs of "real-life" performance setup?
> >>
> >> Maybe find something that already exists + works, and strip it down to
> >> the minimum that other functionality can be built on later.  Get it
> >> running in a few different systems (pd/sc/overtone) and then it's the
> >> standard..
> >>
> >> > For instance with netclock, although I haven't tried it, it seems
> quite
> >> > flexible enough, so except for the
> not-so-immediate-plug-n-playability,
> >> > anything you find problematic with it?
> >>
> >> The main problem is that netclock relies upon local system clocks
> >> being in sync, so you have to run ntpd or ptpd as well.  ntpd is
> >> designed for WANs, can take a long time (15 mins iirc) to settle and
> >> there are various versions with different config files etc.
> >>
> >> Ptpd is better, designed for LANs, has autodiscovery and so on, but
> >> AFAICT is patent encumbered and I had weird problems with
> >> supercollider going crazy with it, don't know why that was.
> >>
> >> Sam Birkhead in Huddersfield has made zosc:
> >> https://github.com/samBiotic/zosc
> >> Julian forwarded an off-list side-thread with him to the list but I
> >> think it got munged...  And only seems to be a single clojure script?
> >> Also relies upon ptpd or similar.
> >>
> >> As I say I think extempore has something, if that works OK maybe we
> >> can use that as the basis.
> >>
> >> alex
> >>
> >> --
> >> http://yaxu.org/
> >> _______________________________________________
> >> eightycolumn mailing list
> >> eightycolumn at multiplace.org
> >> http://multiplace.org/mailman/listinfo/eightycolumn
>
>
>
> --
> http://yaxu.org/
> _______________________________________________
> eightycolumn mailing list
> eightycolumn at multiplace.org
> http://multiplace.org/mailman/listinfo/eightycolumn
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://multiplace.org/pipermail/eightycolumn/attachments/20120413/29938fd9/attachment.html>


More information about the eightycolumn mailing list