[openal] EOL for AL_SOFT_buffer_sub_data and AL_SOFT_buffer_samples

[Chris Robinson]

Hi.

Unfortunately, there are irreconcilable differences with the 
AL_EXT_SOURCE_RADIUS extension and AL_SOFT_buffer_sub_data / 
AL_SOFT_buffer_samples. The latter two have the source property 
AL_BYTE_RW_OFFSETS_SOFT, with a defined value of 0x1031, and is used to 
get the read-write offsets (expressed as bytes) to determine the current 
position and the location for safely writing to a playing source's 
buffer. The former has the source property AL_SOURCE_RADIUS, with a 
defined value of 0x1031, and is used to set and get the source's radius, 
which affects the apparent "width" of the sound.

I would like to implement the AL_EXT_SOURCE_RADIUS extension, but there 
would be an unresolvable question with apps that call
alGetSourceiv(source, 0x1031, ...);
It would be impossible to know if the app is expecting two playback 
offset values to be written, or if it's expecting the source's radius 
expressed as an integer.

The only way to clear this up, without breaking apps that use those 
extensions, is to end-of-life/remove the extensions. In that way, apps 
can see they're not supported and fallback to other methods that still 
work -- as long as they don't have hard requirements for those 
extensions, otherwise there's little I can do.

The only other alternative is to make an OpenAL Soft-specific radius 
extension, which has a different value for the radius property enum, so 
they can all live together. Although that strikes me a poor solution as 
apps would then have to check and handle both extensions to work on 
various implementations. And if AL_EXT_SOURCE_RADIUS is ever promoted to 
core, I wouldn't have the option of avoiding it.


Of course, I know the usefulness of the buffer extensions (although I 
don't know how many people actually use them), so what I'll probably do 
is make another AL_SOFT_buffer_samples-like extension (with a different 
name, so apps don't get confused). This new one would use different enum 
values that don't conflict with AL_EXT_SOURCE_RADIUS, would fix a few 
things in the original extension spec, and probably add a few sample 
types and configurations that OpenAL Soft has supported but weren't 
exposed via the buffer_samples API. Presuming there's enough interest.


But that leaves me in a conundrum. The 1.17 release is coming up soon, 
and I don't know if I'll get the radius extension in for it. So, do I 
leave the buffer extensions in for one more release so apps that need 
them will work with one more release, or do I drop them now since 
they're going to go away anyway and prevent apps from relying on them?


Feedback is most welcome on this issue.