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

Chris Robinson chris.kcat at gmail.com
Wed Apr 2 06:23:40 EDT 2014


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.


More information about the openal mailing list