[openal] How to handle callbacks/the chances of seeing callbacks in OpenALSoft?

Doug Binks doug at enkisoftware.com
Wed Apr 2 07:26:04 EDT 2014

A TCP/IP style select() type function might be useful - add a set of
queries to a set and then either poll for changes or wait on them.

On 2 April 2014 12:23, Chris Robinson <chris.kcat at gmail.com> wrote:

> On 03/30/2014 03:15 PM, Austin Hicks wrote:
>> I'd settle for a good way to be notified of when buffers finish and when
>> sources state change-whether or not I'm implementing this myself.  Does
>> anyone have any design info for this kind of thing?
> There really shouldn't be much of an issue with using a background thread
> that checks every 10ms or so. You probably won't get much better than that
> anyway due to OS scheduling (and OpenAL Soft itself updates every 21~23ms
> by default).
> With Alure, I basically do just what was suggested. Start up a background
> thread, which periodically wakes up and checks if sources have changed
> state, and checks if any streaming sources have processed buffers, and
> calls the appropriate callbacks.
> If that's still a problem, see below.
>  I saw the previous thread about realtime audio and blocking callbacks,
>> and understand why that could be a problem; nevertheless, the case for
>> having OpenALSoft allow it is simple: condition variables, or other
>> cross-thread data structures can be used for notification to something
>> else on another thread.  Is generic callbacks as big a problem to do
>> outside OpenALSoft as I think it is?  I've not yet managed to come up
>> with a good solution, but I may just not be seeing it.
> There's other issues besides real-time blocking. Language bindings, for
> instance, can have varying amounts of difficulty calling into a native
> function from C. Threading can also be an issue since there's no guarantee
> the app and OpenAL Soft would be using the same thread methods, which can
> cause problems if the app expects some thread data to be there in the
> callback that was never set up by the thread creation methods.
> Something I can do, though, is add a new synchronization object. Something
> that could let you check and/or wait for various conditions on a source; a
> state change, a change in the number of processed buffers, a property
> change taking effect, etc. That way you can simply make your thread sleep
> until something happens that you're interested in, then you get woken up
> and can deal with it as you want.
> _______________________________________________
> 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/20140402/7bc275e4/attachment.html>

More information about the openal mailing list