[openal] AL_SOFTX_events feedback

Patrick Baggett baggett.patrick at gmail.com
Sun Sep 27 15:07:28 EDT 2020


On Sun, Sep 27, 2020 at 1:04 PM Chris Robinson <chris.kcat at gmail.com> wrote:

> 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.
>
> This was exactly my reasoning. The wording of it seemed to exclude any
sort of alGetSource()


> 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.
>
> Yes, it is hacky. It was the only solution I could come up with that would
maintain the function's call signature. The idea of a per-source user datum
is just a suggestion that would help my use case. I'm using a source ->
pointer map outside of AL so this would only reduce the memory usage of my
app by some 1-2k at most. Nothing major.

Thanks for your hard work on this!

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


More information about the openal mailing list