[openal] AL_SOFTX_events feedback

[Chris Robinson]

On Sun, 27 Sep 2020 11:43:10 -0500
Patrick Baggett <baggett.patrick at gmail.com> wrote:

> 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.

Thanks for the feedback.

> 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.

Hmm. My first thought was to allow setting user data on a source, e.g.
alSourcePointerSOFT(source, AL_USER_DATA_SOFT, userData);
which can later be retrieved with
alGetSourcePointerSOFT(source, AL_USER_DATA_SOFT, &userData);

Although this wouldn't work given the 'no AL calls in the callback'
restriction. Technically such a call wouldn't be a problem as it
currently stands, but some AL calls could pose a problem if called from
the callback, so it's probably best to not tempt fate.

Having the callback give the source user pointer if the context user
pointer is null feels hacky, especially considering different event
types can handle different object types. It can get tricky knowing what
the user data points to.

> 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?]

Yeah, sorry. The second line was trying to clarify the callback runs
separately from a real-time mixer, and to let potential implementers
know that events should be marshaled to a separate thread where the
callback can be invoked. I suppose I could remove that second part and
just clarify it runs on a separate thread from the mixer, where
non-real-time calls are safe.