[openal] OpenAL Soft 1.21 preparation and extensions

[Patrick Baggett]

Hi Chris,

Where can we find references for these SOFTX extensions? I think
AL_SOFTX_events would be really useful in my application and I might be
able to provide some feedback, but I can't seem to find any references to
it.

--Patrick Baggett

On Fri, Sep 25, 2020 at 8:09 PM Chris Robinson <chris.kcat at gmail.com> wrote:

> 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!
> _______________________________________________
> openal mailing list
> openal at openal.org
> http://openal.org/mailman/listinfo/openal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openal.org/pipermail/openal/attachments/20200926/ed192e1c/attachment.htm>