[openal] Synchronizing 3D sources

[Doug Binks]

The problem is that even with nanosecond precision, the drift will
equal one sample after a few hundred seconds.

The important objective I (and the other use case I'm aware of) is
trying to achieve is to get per-sample synchronization with two or
more samples being played. We don't care (in this context) about the
absolute timing, so drift of any backend or hardware doesn't matter to
us so long as the mixing is accurate to the sample level.

The offset clock is in nanoseconds with a wrap-around time of 58
years, and the sample clock is in samples, with a far larger
wraparound time.

If we can drop the requirement to cope with frequency changes, other
than resetting the sample clock, then this can be made a lot simpler
since we can stick to output sample units - however the current code
works with the exception of sub-sample accurate mixing which is
required when the sources have a different frequency than the output.

On 30 January 2014 19:39, Chris Robinson <chris.kcat at gmail.com> wrote:
> 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.
>
> _______________________________________________
> openal mailing list
> openal at openal.org
> http://openal.org/mailman/listinfo/openal