[openal] EOL for AL_SOFT_buffer_sub_data and AL_SOFT_buffer_samples
chris.kcat at gmail.com
Thu Sep 17 12:39:04 EDT 2015
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.
More information about the openal