[openal] Synchronizing 3D sources

[Doug Binks]

It makes a lot of sense not to encumber the library with any features
which would prevent forward progress on other more important aspects.

I'll see if I can get some feedback on whether 'almost' sample
accurate would do.

The square wave test isn't something I think can be made to
generically work in all circumstances, but it's certainly one which
shows any errors up well.

On 31 January 2014 02:18, Chris Robinson <chris.kcat at gmail.com> wrote:
> 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.