Re: [LAD] OSC for syncing

Hi Victor, On 06/18/2010 11:35 AM, Victor Lazzarini wrote: I can't pretend to be an OSC guru, but I've been thinking and working quite a lot on OSC and timing accuracy. "Syncing" can be many things, but I'll take an example: let's say that a step sequencer sends OSC messages to a sampler. The sequencer might send timestamped messages a bit before they ought to result in playback, to compensate message transport time, as well as latency and related issues on the sampler side. So sequencer sends a message at instant T-1 to tell the sampler to start playback at instant T. First a very practical consideration. If you use liblo, then you can't rely on the high-level API to receive timestamped messages, because it has its own message queues and will delay the message by itself. That forbids taking latency into account. I made a bug report about this: http://sourceforge.net/tracker/?func=detail&aid=2858774&group_id=11… So you'll have to use the liblo lo-level API, which means extra work. Now, the clock issues. OSC timetags are absolute timestamps, so you need a reference clock. On a single system, that will be the system clock, and you will certainly use gettimeofday() (altough some might disagree about this). The problem is that the sound card has its own clock, so you're dealing with two clocks, which causes a variety of problems, as described by Fons in hi essay about Delay Locked loops: http://www.kokkinizita.net/papers/usingdll.pdf /Simplifying it/, those clocks do not run at the same speed, they drift. Plus, there's a jitter between soundcard hardware interrupts and the moment your (JACK or whatever) process callback gets called. It's not getting called as regularly that one would expect. To circumvent these issues, I have been working on libtimefilter (formerly libpendule), which is an implementation of Fons' proposal: http://code.google.com/p/libtimefilter/ Now, last but not least, almost all of these problems would become a souvenir, if JACK supported OSC ports, as it does for MIDI, and that of course both the sender and receiver use that. Hope that helps, -- Olivier