[openal] AL_SOFTX_callback_buffer specification

[Chris Robinson]

On Tue, 14 Apr 2020 21:48:02 +0200
Pol Marcet Sardà <polmarcetsarda at gmail.com> wrote:

> Hello! I'm developing a video game engine, and I'm in the middle of
> implementing the audio system, and me and my friend decided to go with
> OpenAL. Each audio frame I check that sources have enough data, and if
> that's not the case, they are queued a new buffer. This works great!
> But the decoding of audio takes a substantial amount of time (about
> 12% of the total engine time) and I was looking for ways to mitigate
> this issue. I noticed AL_SOFTX_callback_buffer used in the examples,
> but the fact that it is not documented, and that it is not mentioned
> on openal-info, makes it difficult to tell whether it can be used or
> not. What's the state of this extension, and for that matter, most of
> the undocumented extensions?

AL_SOFTX_callback_buffer should only be used for testing and feedback
purposes (API improvement suggestions, missing/desired capabilities,
buggy or unintuitive behavior, etc). Feel free to try it out in any of
your projects to test potential real-world use-cases, but it shouldn't
be used in production/release code until it's finalized (the SOFTX
moniker becomes SOFT) since its subject to incompatible changes. When
I'm more certain about what it will end up like, I'll write up a spec
doc. Currently I'm not sure about what parameters the callback should
get beyond an opaque user-pointer, and a pointer and length for the
sample data to fill in (it could get the buffer and/or source ID, but
they'd be pretty redundant since only one source can use a given
buffer, and a buffer will have an associated user-pointer to hold any
unique instance information it needs).

If the issue you're having is decode time being too high, it's unlikely
the extension will help too much since the callback itself needs to act
quickly, and definitely shouldn't do anything costly like locking or
allocations (which decoder libs may do unexpectedly). Although if the
constant unqueue/buffer/queue is taking up a fair amount of time, the
callback could allow using a lock-less ring buffer to more efficiently
fill the playback queue.

More generally about the currently in-progress extensions:

AL_SOFTX_bformat_hoa - An extension to support second- and higher-
order B-Format sounds, as the original AL_EXT_BFORMAT extension only
supports first-order B-Format. I'm a bit wary with its current design
since it introduces a buffer state that can affect a subsequent
alBufferData call, although I'm not sure of any better way that doesn't
result in a massive number of new format enums. It's not really
dangerous since alBufferData takes the size in bytes which would
prevent overrunning the buffer, but it feels less than ideal. I'm also
not currently aware of much/any content this would be useful for.

AL_SOFTX_effect_chain - An extension to allow the output of one
auxiliary effect slot to feed the input of another auxiliary effect
slot. To chain multiple effects together, instead of each effect being
independent. There's no real hold-up with this, I don't imagine the API
needs any more thinking over, I just hope it's worth enough to have and
doesn't cause any performance or architectural problems down the line,
or encourage inefficient effect use, since effects in general can be
rather costly and don't always need chaining.

AL_SOFTX_events - An extension to have a callback run when certain
events happen (a source stops, a device disconnects, etc), so the app
doesn't have to continually poll to see if anything happened. This has
the similar issue that I don't know what information should be supplied
to the callback, and I also don't know what events would be more or less
useful to have (with the caveat that you can't make OpenAL calls in
the callback, and though it doesn't need to be real-time safe, it
should avoid taking too long).

AL_SOFTX_filter_gain_ex - An extension to allow the filter gain to go
above the original limit of 1.0. This was only added for DSOAL which
(tries to) support EAX on EFX, and EAX's source properties allow
increasing the gain a bit above 0dB, unlike EFX. Though I don't know if
anything actually does that, or if it's not supposed to be clamped
after all the filter properties are calculated. This probably won't
stick around.

AL_SOFTX_map_buffer - An extension to "map" or access a buffer's sample
data. This too was added to help DSOAL since DSound can map a buffer's
samples and update them when in use, while standard OpenAL can't. This
does have potential utility outside of DSOAL though, since it can avoid
an extra buffer copy when filling in a buffer. It's not too much of a
saving, but it might be worth having regardless. Though apps would need
a fallback anyway when the extension isn't available, so I'm not sure.

> Lots of pages are dead or broken, like http://icculus.org/alextreg/ or
> http://developer.creative.com/ (referenced in the wiki), getting HRTF
> menus working was only possible thanks to examples/alhrtf.c Is there
> a place with a clear specification of the extensions supported by
> OpenAL-soft?

OpenAL Soft-specific extensions are listed here:
<https://openal-soft.org/openal-extensions/>

A more thorough extension list is here (not all of which are supported
by OpenAL Soft): <https://github.com/openalext/openalext>
Although it hasn't been updated recently and may not have newer OpenAL
Soft extensions. If you have specific questions about any of them, I
can try to answer.

> I'd also like to say, thank you, kcat, for all the amazing work you
> do!

Thanks, and you're welcome. :)