[openal] Synchronizing 3D sources

[Doug Binks]

[Just an FYI, TL;DR: wait until I finish the prototype.]

I've started a prototype implementation, with temporary extension name
AL_SOFT_device_clock on a branch on my github fork of OpenAL (otherwise
unchanged from the main repo).

https://github.com/dougbinks/openal-soft/commits/Device_Clock

Currently the functionality is just for getting the required data
atomically, as per example I've added here:

https://github.com/dougbinks/openal-soft/commit/6ede7493ef42eb355f52436aee8ca99cf51153f3

The extension add three source enums, only the first two of which work as
yet:

AL_SAMPLE_OFFSET_DEVICE_CLOCK_SOFT,
AL_SAMPLE_OFFSET_LATENCY_DEVICE_CLOCK_SOFT and
AL_PLAY_ON_DEVICE_CLOCK_SOFT.


AL_SAMPLE_OFFSET_DEVICE_CLOCK_SOFT returns source offset, output
sample count, output frequency, and output update size.


AL_SAMPLE_OFFSET_LATENCY_DEVICE_CLOCK_SOFT returns source offset in
32.32 format as per AL_SAMPLE_OFFSET_LATENCY along with latency,
output sample count, output frequency and output update size.


These should be sufficient for deciding when to play a source with the
new (not implemented yet) AL_PLAY_ON_DEVICE_CLOCK_SOFT timing.


After some thought the device clock is just in output samples for now.
This is sufficient for the use cases I am aware of for now, and we can
add a more generally applicable clock later, but we'll likely need
sub-sample timing precision if we're to support synchronization of
sources with different frequencies from the output clock.




On 24 January 2014 14:39, Doug Binks <doug at enkisoftware.com> wrote:

> I'll have a think - this would accumulate a small amount of error but it
> should be OK. Another potential would be to recalculate the number of
> samples when the frequency is changed into the new sample rate.
>
>
> On 24 January 2014 14:22, Chris Robinson <chris.kcat at gmail.com> wrote:
>
>> On 01/24/2014 05:14 AM, Doug Binks wrote:
>>
>>> Sounds good - presumably there are no current plans to add a device
>>> output
>>> frequency change to the spec, but can always change the code at that
>>> point
>>> if needed.
>>>
>>
>> Hmm, that's a good point, actually. The playback frequency can change if
>> a new context is created and specifies an ALC_FREQUENCY attribute.
>>
>> In that case, a better option would be to store the clock time in the
>> device, instead of the samples mixed. Then you'd increase the clock time in
>> aluMixData by converting the number of samples to mix into a time increment.
>>
>> _______________________________________________
>> openal mailing list
>> openal at openal.org
>> http://openal.org/mailman/listinfo/openal
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openal.org/pipermail/openal/attachments/20140127/5a498ea5/attachment.html>