[openal] Preparing for OpenAL Soft 1.23.1

[Chris Robinson]

Hi,

OpenAL Soft 1.23.1 is soon to be released. Presuming no significant 
issue pops up, I'd expect it to be early next week. This release fixes a 
few compilation issues, and has a few new extensions like:

AL_SOFT_UHJ_ex 
<https://openal-soft.org/openal-extensions/SOFT_UHJ_ex.txt>, adding a 
few more sample types to UHJ formats (muLaw, aLaw, IMA4/MS ADPCM).

AL_SOFT_buffer_length_query 
<https://openal-soft.org/openal-extensions/SOFT_buffer_length_query.txt>, 
simplifying and closing some gaps in buffer attribute queries.

AL_SOFT_source_start_delay 
<https://openal-soft.org/openal-extensions/SOFT_source_start_delay.txt>, 
adding methods to play a source at a particular time point or with a 
delay, instead of "immediately".

AL_EXT_STATIC_BUFFER 
<https://github.com/Raulshc/OpenAL-EXT-Repository/blob/master/AL%20Extensions/AL_EXT_STATIC_BUFFER.txt>, 
which isn't really new, but allows apps to specify custom storage for 
buffer samples.

There are also improvements to EAX compatibility, improved quality of 
the reverb modulator, and support for native ADPCM buffers (without 
decompression on load).

If there are any problems you're aware of, please report it. If any 
features sound of interest, give them a try.


I do have one question to pose to get feedback on. This issue 
<https://github.com/kcat/openal-soft/issues/831> was fixed by adding a 
game_compat config option to restore an old extension (at the cost of 
disabling a newer one). I am curious if it might be a good idea to 
detect that game and enable the compatibility option by default when 
detected. This would be the first instance of OpenAL Soft doing some 
game-specific behavior, though since it requires the user to manually 
replace the game's existing shared library with an alternate one, maybe 
it's not a problem to have the user manually set the game_compat option 
too. Thoughts?

One further note that I forgot to mention with 1.23.0, that the 1.23 
series will likely be the last requiring C++14. With 1.24, the plan is 
to move on to C++17, which probably means GCC 8 or newer (as opposed to 
GCC 5 currently), and whatever version of Clang and MSVC that has proper 
C++17 support.

If there's any questions, comments, or concerns, don't hesitate to bring 
them up.