[openal] Synchronizing 3D sources

[Chris Robinson]

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.