[openal] AL_SOFTX_events feedback

[Patrick Baggett]

Hi Chris,

Thanks for the document. I've just done some initial implementation of
using AL_SOFTX_events. It's very useful for my use case, explained below. I
also have two suggestions:
1) Adding per source user data would be more useful
2) clarify Q/A slightly.

These are explained more below.

-

I am working on a game for the Raspberry Pi. I have a fixed pool of sources
that are allocated dynamically as sound effects play. For memory and CPU
reasons, I like to keep this number low. When I begin playing a sound, I
loop through the audio engine structures looking for a sound that has the
state of "FREE". If none are found, then I have to loop through the sources
and call alGetSourcei(..., AL_SOURCE_STATE, ...) to see if any are
AL_STOPPED / AL_INITIAL, so I can reuse them.

AL_SOFTX_events allows me to eliminate this second step. When a source
transitions to AL_STOPPED, I can update the corresponding data structure to
ensure that the engine knows this source can be safely reused. If no
sources are free, then I can directly engage the algorithm to check for
terminate-by-priority. It's not going to be a huge performance win, but it
makes the code cleaner in my opinion.

However, I did have to add a map from source -> engine data structure so
that inside the callback I can find the corresponding engine data structure
that owns this source. My suggestion then is that adding per-source user
pointer would eliminate the need for this. I'm not sure how that would
interact with the provided user pointer callback. Maybe something like if
callback userdata is NULL, then use per-source userdata, otherwise, use
global userdata. I can't imagine a usecase for both pointers in the
callback.

I haven't implemented music, but it will be done using queued buffers and
responding to buffers being decoded. The AL_EXT_STATIC_BUFFER looks like a
great way to reduce copying as well.

--
The text about whether it's safe to do other operations (locks, I/O, etc)
took me about three readings to finally understand what is being said. The
second sentence threw me off because it seemed like it was contradicting
the first:

1) The callback does not need to be real-time safe, so locks and I/O are
allowed.
[OK, so we're fine]

2) With a real-time mixer, the events can reasonably be expected to be
marshalled to an event-handler thread where the callback can be run without
interrupting the mixer.
[Wait, isn't this a real-time mixer? So do I need to marshal events?]

I think it's more clear to simply leave out the second sentence.

--Patrick Baggett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openal.org/pipermail/openal/attachments/20200927/ab6fd086/attachment.htm>