Given that they're nearly identical, it should be relatively simple to use the
same effect state to process either of them, similar to the reverbs. The big
differences seem to be the delay range (much shorter with flanger) and the
defaults.
Command line parameters and filenames are now unicode-aware (the .def files
should be UTF-8 encoded, if they contain any non-ASCII-7 characters). Unicode
characters might not display correctly in the console, but it should process
them correctly.
This is rather ugly, but it's necessary to get a proper export configuration.
The issue was that the main OpenAL target library name is set to soft_oal when
the router is being built, which is incorrect for the exported config library.
Exporting the router would have the incorrect name of OpenAL::Router.
So this change has the router use the OpenAL target name when it's built, which
is good since it will have the standard OpenAL lib name for apps to link to and
get the OpenAL::OpenAL export name. The main library's target name is changed
in this case to avoid conflicts.
Experimental, Windows only. This is intended as an alternative to Creative's
router DLL, fixing a few issues with it (falsely reporting extensions that
aren't supported, not being able to query the ALC version without a device, and
not being able to use ALC extension functions).
When enabled OpenAL Soft's DLL is built as soft_oal.dll, while the router is
OpenAL32.dll.
This is just for the output limiter right now, but in the future can be used
for the compressor EFX effect. The parameters are also hardcoded, but can be
made configurable after 1.18.
Clang does not allow using C11's atomic_load on const _Atomic variables.
Previously it just disabled use of C11 atomics if atomic_load didn't work on a
const _Atomic variable, but I think I'd prefer to have Clang use C11 atomics
for the added features (more explicit memory ordering) even if it means a few
instances of breaking const.
This is intended to do conversions for interleaved samples, and supports
changing from one DevFmtType to another as well as resampling. It does not
handle remixing channels.
The mixer is more optimized to use the resampling functions directly. However,
this should prove useful for recording with certain backends that won't do the
conversion themselves.
