[openal] OpenAL Soft 1.19.0 released!

[Ian Reed]

Pretty awesome! Thanks for your hard work on this.

I see you added pitch and frequency shifting for EFX.
Will that shift pitch for the direct sound, or only reverb?
I can adjust the pitch of a source without EFX, but that just alters the 
frequency without preserving the duration.
Does the new pitch shifting effect retain the original duration of the 
sound?

With your discerning ear, how does the 24-bit dual-ear HRTF data set 
compare with the data set OpenAL Soft used in the past?
Any thoughts on how it compares with the HRTF in Google Resonance, 
Oculus, or SteamAudio?
What does "dual-ear" mean in this context?

Downloading the Windows binaries, I see that there are 3 HRTF def files, 
with CIAIR.def being the largest.
Which is best to use, and where do I need to place the file?
Or are the best HRTF data sets built in to the OpenAL Soft dll? 
openal-info32.exe seemed to indicate them being built in.

When I run openal-info32.exe I see:
Max auxiliary sends: 2
Didn't that used to be 4?

Creating a lower level API sounds nice.
It doesn't matter to me if the API or ABI is stable since I package it 
with games I ship and don't mind updating a bit of my own code when 
upgrading.
If you moved away from LGPL, what license would you use?

Thanks again,
Ian Reed


On 9/6/2018 10:01 PM, Chris Robinson wrote:
> Hello,
>
> OpenAL Soft 1.19.0 has been release and is ready to download:
>
> http://openal-soft.org/
>
> Notable changes include implementations of EFX's Pitch Shifter, 
> Frequency Shifter, and Autowah effects, a higher quality 23rd order 
> sinc resampler, support for 24-bit dual-ear HRTF data sets, a number 
> of general efficiency improvements, fixes for the reverb's density and 
> panning parameters, and more.
>
> One important thing to note about this release is that 32-bit x86 
> builds now rely on SSE2 by default (the compiler is set to generate 
> SSE1 and SSE2 opcodes for floating-point math). This makes SSE2 
> required, even if it's disabled via the config option. The vast 
> majority of processors released in the last 10+ years should have no 
> problem with this. This was done for performance reasons, since SSE 
> has the capability to more efficiently deal with denormal 
> floating-point numbers that occur with various DSP stages, which 
> normally severely hamper performance on x87 units. There are 
> build-time options to disable this behavior and revert to x87 (or 
> x87+SSE1-only) codegen if desired, but the recommendation is to leave 
> it as SSE2 unless you really need otherwise.
>
> As has been the case, this release came out a fair bit later than I 
> intended, though it did allow for some last-minute improvements that 
> people have asked for. There are other improvements I would've liked 
> to include as well, but decided to release this as it is now and 
> instead have those other improvements for a future 1.19.1 release, 
> which shouldn't take nearly as long since the last release.
>
> Looking farther to the future, I'm giving some serious thoughts to 
> restructuring and pseudo-splitting the project up. The general plan 
> would be to separate lower-level functionality to a (reusable) static 
> library or libraries that would be capable of doing all the necessary 
> processing for rendering, filters, and effects, and OpenAL Soft would 
> essentially sit on top of and utilize that with the standard OpenAL 
> API. This would provide options for people that want something even 
> more lower level than what OpenAL would normally provide for, and 
> enables a way to play around with and implement features that may 
> either not be suitable for OpenAL or may need some significant 
> consideration on how to best expose it through the OpenAL API. Such a 
> low-level library would likely not have a stable API or ABI.
>
> This would also give me a way to audit the code, get permission for 
> changing the license of or rewrite anything that's currently LGPL as 
> its moved over to the low level library, and redoing the interface 
> between the OpenAL API and the low level library, paving the way to 
> get the library relicensed.
>
> I don't imagine such a change would be fast or easy, however. While 
> nice, I wouldn't expect it to be fully done for 1.20, or necessarily 
> even 1.21. But it's what I currently have in mind.
>
> Anyway, questions, concerns, and comments are welcome. Thanks!
> _______________________________________________
> openal mailing list
> openal at openal.org
> http://openal.org/mailman/listinfo/openal