[whatwg] Timing API proposal for measuring intervals

[Robert O'Callahan]

, On Fri, Jul 8, 2011 at 2:54 PM, James Robinson <jamesr at google.com> wrote:

> On Thu, Jul 7, 2011 at 7:36 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>>
>> Using this value as a clock for media synchronization sounds appealing but
>> is complicated by audio clock drift. When you play N seconds of audio, it
>> might take slightly more or less time to actually play, so it's hard to keep
>> media times perfectly in sync with another timing source. Just something to
>> keep in mind.
>>
>
> True.  On OS X, however, the CoreVideo and CoreAudio APIs are specified to
> use a unified time base (see
> http://developer.apple.com/library/ios/#documentation/QuartzCore/Reference/CVTimeRef/Reference/reference.html)
> so if we do end up with APIs saying "play this sound at time X", like Chris
> Roger's proposed Web Audio API provides, it'll be really handy if we have a
> unified timescale for everyone to refer to.
>

Is that unified time base in sync with the system clock, and how accurate is
it? I'm concerned about the possibility that it's not feasible to keep the
audio hardware clock in sync with the system clock, at least on some
platforms. In that case, we probably need to keep media playback and
animations in sync with the audio hardware clock, and we could even expose
that via some DOM API, but you might not want to use the same clock for
other purposes, such general performance timing for example ... I've heard
the audio clock drift is often significant.

I'm not sure if this is a real problem or not, I just want to make sure.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]