<div dir="ltr"><div>Hi Chris,</div><div><br></div><div>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.</div><div><br></div><div>--Patrick Baggett<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 25, 2020 at 8:09 PM Chris Robinson <<a href="mailto:chris.kcat@gmail.com">chris.kcat@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
It's probably well about time that OpenAL Soft 1.21 gets ready for a<br>
release, so let's consider this a call for testing to make sure I<br>
haven't missed any glaring issues or anything.<br>
<br>
Relatedly, I'd like to bring attention to the in-progress extensions<br>
that have been piling up with recent releases. Some of these I haven't<br>
mentioned yet, one I threw together for my own purposes but may remove<br>
it since it doesn't seem particularly useful, but the more that I can<br>
deal with one way or another, the better.<br>
<br>
* AL_SOFTX_bformat_hoa<br>
<br>
Adds support for higher-order B-Format sources. AL_EXT_BFORMAT<br>
supports first-order, but there is second- and higher-order content<br>
floating around out there that can provide a sharper positioning<br>
response, presuming an output decoder that works with a suitably high<br>
order). I'm not sure if anyone is even using first-order B-Format, so I<br>
don't know how useful this would be (though I did hear during the UE5<br>
presentation that they support soundfield recordings, so there does<br>
seem to be at least some desire for B-Format given a large enough<br>
scope).<br>
<br>
My main issue with this is I'm not sure if a separate buffer state set<br>
prior to loading the data is the best method, versus new format enums<br>
or something else. New format enums would mean quite a lot of new<br>
enums, as each order would need 6 or 8 new format enums, while a<br>
separate integer property is just that. Alternatively, a new loading<br>
function could take an extra parameter.<br>
<br>
* AL_SOFTX_callback_buffer<br>
<br>
A more recent addition, allows a callback to run in the mixer when it<br>
needs more samples for mixing a source. Basically allows for no extra<br>
buffering latency for real-time audio generators (not decoders), or<br>
more efficient streaming using something like a shared ring buffer.<br>
<br>
My main issue here is whether the callback itself is well enough<br>
defined. Given a real-time processing restriction, if it provides<br>
enough information or if some parameters/the return value should be<br>
tweaked (bytes or sample frames?).<br>
<br>
* AL_SOFTX_convolution_reverb<br>
<br>
Most recent addition, a convolution reverb effect that applies a<br>
predefined impulse response. More costly and less flexible than<br>
standard and EAX reverb, but much more realistic/accurate since it's<br>
directly applying a response measurement (which could be a real<br>
room/environment, or a particular hardware response that has a<br>
desirable aural quality).<br>
<br>
This still needs a bit of work for adding panning and rotation, maybe<br>
an initial delay setting, and maybe even roughly detect the decay rate<br>
to apply automatic distance modeling like standard and EAX reverb do.<br>
<br>
* AL_SOFTX_effect_target<br>
<br>
An older one. Allows an effects to feed into another, so you can add<br>
chorus or reverb to the distortion and/or autowah output, for example,<br>
rather than effects always being done independent of each other. I<br>
remember this kind of thing being asked for, but I haven't seen much<br>
feedback. Presuming there's no objections, this will probably be ready<br>
soon.<br>
<br>
* AL_SOFTX_events<br>
<br>
Another somewhat older one. Basically allows for callback notifications<br>
that a source stops (or otherwise changes state), or that it processed<br>
some buffers, or that the device disconnected, so the app doesn't have<br>
to constantly call into the library to poll these things. It used to<br>
also report deprecated function calls and error conditions, though I<br>
recently removed that as they seem better suited to a proper debug API<br>
extension instead of an asynchronous event extension.<br>
<br>
This is something I'd really like feedback on, especially as related to<br>
the usefulness of the provided events, or if more information could be<br>
provided through the callback, before committing to it as it currently<br>
is (new events can always be added in the future).<br>
<br>
* AL_SOFTX_filter_gain_ex<br>
<br>
I added this on a whim when I noticed DSound+EAX allowed setting a<br>
filter frequency volume greater than 0dB (1.0 gainhf), whereas EFX<br>
limits to 1.0 gain, and I wanted to see if it would help with some audio<br>
problems I was hearing with DSOAL. It didn't help, and given how<br>
multiple parameters contribute to the filter in DSound+EAX, I'm not<br>
sure that having it >0 doesn't just offset it back up when lowered, with<br>
the final result still being internally limited to 0dB. Consequently,<br>
I'll probably be removing this.<br>
<br>
* AL_SOFTX_map_buffer<br>
<br>
This was also mostly added for DSOAL, which was to aid in the fact that<br>
DSound can access and modify buffer samples whenever. To handle this<br>
otherwise, it would need to stream which requires more resources and<br>
data management, often when it's not actually necessary (since DSound<br>
doesn't by default assume static buffer data).<br>
<br>
Now with the callback buffer, I don't think there's as much need for<br>
this with DSOAL. But I could still see it useful, if sound loading<br>
performance is an issue, to prepare the AL buffer then map it and load<br>
samples directly into it without copying from an intermediate buffer.<br>
It could even be loaded over time without using a streaming source and<br>
buffer queue. But even then, a callback buffer may offer the best<br>
loading performance with only a bit more CPU use in the mixer.<br>
<br>
<br>
Anyway, that's what's going on currently. The 1.21 release may be coming<br>
up soon, and feedback on these extensions would be helpful in getting<br>
them finalized.<br>
<br>
Thanks!<br>
_______________________________________________<br>
openal mailing list<br>
<a href="mailto:openal@openal.org" target="_blank">openal@openal.org</a><br>
<a href="http://openal.org/mailman/listinfo/openal" rel="noreferrer" target="_blank">http://openal.org/mailman/listinfo/openal</a><br>
</blockquote></div></div>