[openal] Synchronizing 3D sources
chris.kcat at gmail.com
Thu Jan 30 13:39:23 EST 2014
On 01/30/2014 09:16 AM, Doug Binks wrote:
> Device time uses samples output plus an offset internally. This way we
> do not accumulate errors, which quickly add up even with a nanosecond
> accurate clock. The offset stays at 0 unless a frequency change
> occurs, at which point the offset is set to the current time and the
> output sample count reset to 0.
Note that with a default update size of 1024 samples, with the default
playback rate of 44100hz, converting samples to nanoseconds and adding
that to the clock time (rather than keeping samples and converting to
nanoseconds on request) will only introduce an error/drift of about
-28ns per second.
I'm not sure this is that big of a deal, all considered. I imagine the
timing drift from the actual audio hardware, and any resampling from the
underlying device software (e.g. alsa's dmix, pulseaudio, dsound) would
be far more. Storing it internally as a nanosecond clock also avoids
overflow problems when you try to convert large sample counts;
samples*1000000000/44100 would overflow even a 64-bit integer if samples
was left to accumulate for about 2 days.
More information about the openal