[openal] Synchronizing 3D sources

[Doug Binks]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openal.org/pipermail/openal/attachments/20140128/f68e709f/attachment.html>