[openal] Synchronizing 3D sources

[Chris Robinson]

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.