It would be good if there were a high precision solution for NTP on a
LAN (on stratum > 3). On the other hand, it is not recommended to
mess with NTP on a local level, because if something goes wrong, all
local clocks go wrong.
Perhaps it would be the right time for an OSCTime reference
implementation as a parallel layer to NTP.
>hi,
>
>I have experimented with sync-ing generative computer apps in a
>number of ways.
>
>Never did a proper experiment so was just to ear responses.
>
>Found the timestamped udp network to be a real problem
>
>The audio sync was real good in terms of stop/start and progression
>through score.
>
>However another approach that I tried was using NTP. If the laptops
>were allowed to run for a bit and settle there system clocks I found
>that it was possible to queue events against the system times.
>
>In direct response to your question I find the motu drivers tend to be
>latency stable once running so there tends not to be jitter with the
>latency time.
>
>Scott
>
>On Thu, Dec 17, 2009 at 4:28 AM, Andrew Sorensen <andrew_at_moso.com.au> wrote:
>> OK, so hopefully all of this is going to make some sense :)
>>
>> I've been building some more advanced sync/clock related stuff into
>> Impromptu recently and am getting some pretty good results. My question to
>> the list is that I'm looking for ideas about the most accurate way to test
>> the sync without resorting to specialist hardware (GPS clocks, network cards
>> with timestamping etc.).
>>
>> At the moment my testing approach is to schedule regular pulses from up to 8
>> host machines running Impromptu and record one output channel of each into
>> another machine with an 828. I can then measure the difference between the
>> pulse times in samples between the (up to 8) recorded audio channels. This
>> seems a pretty accurate test and I'm getting a reliable sync and my early
>> experiments indicate an offset range between 1 and 5 samples (< 100
>> microseconds at 44.1k).
>>
>> The sync results (i.e. the measured clock times of the hosts involved) as
>> reported by the "impromptu time server" confirms my audio results but
>> paranoia of the unknown remains strong :)
>>
>> My paranoia is that there are going to be buffering issues with the
>> hardware/device drivers as well as delay on the wire etc.. I don't have
>> much experience with these issues. How much variation should I expect
>> between each hosts audio data leaving its DAC and being successfully
>> processed (i.e. both ADC and Device Driver latency) via the 828. How much
>> should I be worried about the latency of the audio signal from the time it's
>> sent from each host to the time it's received. It's not the overall but the
>> relative delays I'm primarily concerned about. Are we talking nanoseconds
>> or microseconds of difference between each sending host here?
>>
>> My assumption with all of this is that I'm going to get better accuracy
>> (with less precision) from an audio signal than sending time-stamped UDP
>> over a gigabit LAN?
>>
>> If anyone has any thoughts on the accuracy of my tests and what I might do
>> differently to improve upon them (without resorting to specialist hardware)
>> I'd love to hear them. I'm running OSX but thoughts relating to any
>> OS/audio hardware welcome.
>>
>> Cheers,
>> Andrew.
>>
--
.
Received on Fri Dec 18 2009 - 17:44:25 GMT