[openal] OpenAL Soft 1.19.0 released!
Chris Robinson
chris.kcat at gmail.com
Fri Sep 7 00:01:04 EDT 2018
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!
More information about the openal
mailing list