[openal] Synchronizing 3D sources

[Doug Binks]

Makes sense. Since this needs new code for atomically getting a device
timer etc., also adding code for this shouldn't be too much of an extra
problem although it does add to device maintenance costs.


On 24 January 2014 13:29, Chris Robinson <chris.kcat at gmail.com> wrote:

> On 01/24/2014 03:43 AM, Doug Binks wrote:
>
>> That sounds similar to what we were thinking.
>>
>> For device clock, one extra issue is that the programmer needs to know
>> when
>> to submit the play request in order to ensure the buffer can be queued
>> before the device mixes the next output buffer. So we may also need to
>> query the device output buffer size - I'm not sure if that's already in
>> the
>> extension spec.
>>
>
> It should be enough for the app to know the update/period time and add
> that to the retrieved clock time (i.e. a time or frequency derived from
> UpdateSize). So even if the clock updates just after you read it, you will
> still specify an equal or larger clock time to get accurate timing.
>
> Currently you could get that info with the ALC_REFRESH value (update time
> = clock_res / refresh), although like I noted in another message, that's
> not the best idea because the refresh is not a logical product of the
> update size (it currently is, but that's an implementation detail that
> could change).
>
> _______________________________________________
> 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/20140124/561aa535/attachment.html>