[openal] Synchronizing 3D sources

[Doug Binks]

The prototype implementation including the proposed changes is now up
on my github fork
https://github.com/dougbinks/openal-soft/commits/Device_Clock

The code currently doesn't handle sub-sample accuracy, so you cannot
align two sources with the same frequency but one which is different
from the device output to sample precision. I'm now going to work on
that aspect.

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.

I've not been able to test device frequency changes as yet though.

On 28 January 2014 11:02, Doug Binks <doug at enkisoftware.com> wrote:
> Re: time vs samples I'm more worried about the extra complexity for the main
> use cases I know of than precision, but it's true that this does make the
> code completely device frequency neutral.
>
> I do need to check out the sample mixing process more in depth to ensure the
> mix can align two same frequency samples when they're on a different clock,
> which will require sub-sample accurate timing. Currently I just offset the
> write output which makes things really easy, but won't work for different
> frequencies.
>
> Thanks for the info on alMain, SOFTX etc., will get to work on all that!
>
> Many thanks for all the feedback!
>
>
> On 28 January 2014 01:19, Chris Robinson <chris.kcat at gmail.com> wrote:
>>
>> On 01/27/2014 02:16 PM, Doug Binks wrote:
>>>
>>> * Output frequency - indeed I think this could disappear from the return
>>> as
>>> it's relatively non volatile. However I'd like to leave the option to get
>>> samples rather than time as it makes the code easier to use. Adding a get
>>> time rather than samples as per latency makes sense though for some
>>> cases.
>>
>>
>> It's possible to convert the clock time (and update time) back to sample
>> count if needed (at microsecond resolution you should be able to convert
>> back and forth just fine up to 500Khz, and nanosecond should handle up to
>> 500Mhz). By having the clock in microseconds or nanoseconds, an app can also
>> convert it directly to/from the source buffer's sample rate if it needs to,
>> and avoid the device's rate altogether... you can largely ignore the fact
>> that the device has a sample rate and just consider the sources
>> individually.
>>
>>
>>> Please be as mean as you can with the code, even though it's just a
>>> prototype to show this can work. Meanwhile I'll look into the proposed
>>> changes and clean up the example a bit. I'm trying to stay away from
>>> using
>>> SDL for now to reduce dependencies with the example I wrote hence the
>>> slight repeat of code.
>>
>>
>> Aside from stuff already mentioned, in-progress extensions should have
>> their tokens and things added to the private alMain.h instead of the public
>> alext.h. The extension string should also use SOFTX instead of SOFT while
>> it's being worked on and is subject to changes. And since it will probably
>> be adding new device-level queries and methods (I imagine there will be a
>> new alGetInteger64vSOFT function to get the device clock on its own), it
>> should be an ALC extension.
>>
>> _______________________________________________
>> openal mailing list
>> openal at openal.org
>> http://openal.org/mailman/listinfo/openal
>
>