<div dir="ltr"><div>Hi Chris,</div><div><br></div><div>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:</div><div>1) Adding per source user data would be more useful<br></div><div>2) clarify Q/A slightly.<br></div><div><br></div><div>These are explained more below.<br></div><div><br></div><div>-<br></div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>--</div><div>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:</div><div><br></div><div>1) The callback does not need to be real-time safe, so locks and I/O are allowed.</div><div>[OK, so we're fine]<br></div><div><br></div><div>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.</div><div><div>[Wait, isn't this a real-time mixer? So do I need to marshal events?]<br></div></div><div><br></div><div>I think it's more clear to simply leave out the second sentence.<br></div><div><br></div><div>--Patrick Baggett<br></div><div></div></div>