[openal] OpenAL Soft 1.19.0 released!

[Chris Robinson]

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!