[openal] Synchronizing 3D sources
chris.kcat at gmail.com
Thu Jan 30 20:18:55 EST 2014
On 01/30/2014 11:01 AM, Doug Binks wrote:
> 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.
I'm not sure sample-perfect timing should be a reliable feature. The
problem is when the audio clock isn't directly derived from the number
of processed samples, but rather, the number of samples processed is
derived from the audio clock. Or if the returned clock time and source
offsets are interpolated in some way.
Granted this isn't much of an issue for OpenAL Soft right now since the
clock would be based on the number of samples and not be interpolated.
But I'm not sure if that will always be the case, or if other
implementations might want to do it differently. I actually have some
pretty ambitious (if long-term) plans for the mixer that would decouple
it from property processing, making it completely lockless and perhaps
getting really low latencies, which would require rethinking how timing
works. Though even if it doesn't go that far, the way timing works could
still change to give better granularity than the 20+ms it currently has.
So all said, I'm not sure your example of being able to play one square
wave, then time-start another square wave so that they perfectly cancel
out, would be able to reliably work.
Though if anyone else wants to weigh in on the issue, please do. Right
now I'm mainly working with hypotheticals, trying to avoid making
guarantees that could prevent future internal improvements.
More information about the openal