[openal] Synchronizing 3D sources

Doug Binks doug at enkisoftware.com
Fri Jan 24 07:34:59 EST 2014

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>

More information about the openal mailing list