[openal] OpenAL Soft 1.21 preparation and extensions

Chris Robinson chris.kcat at gmail.com
Fri Sep 25 21:08:41 EDT 2020


Hello,

It's probably well about time that OpenAL Soft 1.21 gets ready for a
release, so let's consider this a call for testing to make sure I
haven't missed any glaring issues or anything.

Relatedly, I'd like to bring attention to the in-progress extensions
that have been piling up with recent releases. Some of these I haven't
mentioned yet, one I threw together for my own purposes but may remove
it since it doesn't seem particularly useful, but the more that I can
deal with one way or another, the better.

* AL_SOFTX_bformat_hoa

Adds support for higher-order B-Format sources. AL_EXT_BFORMAT
supports first-order, but there is second- and higher-order content
floating around out there that can provide a sharper positioning
response, presuming an output decoder that works with a suitably high
order). I'm not sure if anyone is even using first-order B-Format, so I
don't know how useful this would be (though I did hear during the UE5
presentation that they support soundfield recordings, so there does
seem to be at least some desire for B-Format given a large enough
scope).

My main issue with this is I'm not sure if a separate buffer state set
prior to loading the data is the best method, versus new format enums
or something else. New format enums would mean quite a lot of new
enums, as each order would need 6 or 8 new format enums, while a
separate integer property is just that. Alternatively, a new loading
function could take an extra parameter.

* AL_SOFTX_callback_buffer

A more recent addition, allows a callback to run in the mixer when it
needs more samples for mixing a source. Basically allows for no extra
buffering latency for real-time audio generators (not decoders), or
more efficient streaming using something like a shared ring buffer.

My main issue here is whether the callback itself is well enough
defined. Given a real-time processing restriction, if it provides
enough information or if some parameters/the return value should be
tweaked (bytes or sample frames?).

* AL_SOFTX_convolution_reverb

Most recent addition, a convolution reverb effect that applies a
predefined impulse response. More costly and less flexible than
standard and EAX reverb, but much more realistic/accurate since it's
directly applying a response measurement (which could be a real
room/environment, or a particular hardware response that has a
desirable aural quality).

This still needs a bit of work for adding panning and rotation, maybe
an initial delay setting, and maybe even roughly detect the decay rate
to apply automatic distance modeling like standard and EAX reverb do.

* AL_SOFTX_effect_target

An older one. Allows an effects to feed into another, so you can add
chorus or reverb to the distortion and/or autowah output, for example,
rather than effects always being done independent of each other. I
remember this kind of thing being asked for, but I haven't seen much
feedback. Presuming there's no objections, this will probably be ready
soon.

* AL_SOFTX_events

Another somewhat older one. Basically allows for callback notifications
that a source stops (or otherwise changes state), or that it processed
some buffers, or that the device disconnected, so the app doesn't have
to constantly call into the library to poll these things. It used to
also report deprecated function calls and error conditions, though I
recently removed that as they seem better suited to a proper debug API
extension instead of an asynchronous event extension.

This is something I'd really like feedback on, especially as related to
the usefulness of the provided events, or if more information could be
provided through the callback, before committing to it as it currently
is (new events can always be added in the future).

* AL_SOFTX_filter_gain_ex

I added this on a whim when I noticed DSound+EAX allowed setting a
filter frequency volume greater than 0dB (1.0 gainhf), whereas EFX
limits to 1.0 gain, and I wanted to see if it would help with some audio
problems I was hearing with DSOAL. It didn't help, and given how
multiple parameters contribute to the filter in DSound+EAX, I'm not
sure that having it >0 doesn't just offset it back up when lowered, with
the final result still being internally limited to 0dB. Consequently,
I'll probably be removing this.

* AL_SOFTX_map_buffer

This was also mostly added for DSOAL, which was to aid in the fact that
DSound can access and modify buffer samples whenever. To handle this
otherwise, it would need to stream which requires more resources and
data management, often when it's not actually necessary (since DSound
doesn't by default assume static buffer data).

Now with the callback buffer, I don't think there's as much need for
this with DSOAL. But I could still see it useful, if sound loading
performance is an issue, to prepare the AL buffer then map it and load
samples directly into it without copying from an intermediate buffer.
It could even be loaded over time without using a streaming source and
buffer queue. But even then, a callback buffer may offer the best
loading performance with only a bit more CPU use in the mixer.


Anyway, that's what's going on currently. The 1.21 release may be coming
up soon, and feedback on these extensions would be helpful in getting
them finalized.

Thanks!


More information about the openal mailing list