[openal] Format clarification
chris.kcat at gmail.com
Wed Dec 17 12:40:39 EST 2014
On 12/17/2014 08:06 AM, Richard Furse wrote:
> I can see a change in our codebase from 2010 where we changed this
> from int32 to float. Are others assuming floats?
OpenAL Soft treats those formats as floats. Though the name makes it
look like int (since it's just "32" instead of "_FLOAT32"), it doesn't
make much sense as int for a few reasons:
There are no int32 mono or stereo formats.
There would be no float32 multichannel formats to match the float32 mono
and stereo formats (from AL_EXT_FLOAT32).
As far as I know, most modern audio codecs natively decode to, if not
int16, to float32, which makes int32 less useful.
That said, OpenAL Soft does have an AL_SOFT_buffer_samples extension
which provides support for int8, uint8, int16, uint16, int24, uint24,
int32, uint32, float, and double sample types (easily extendable to
more). However, there's a compatibility issue that prevents me from
suggesting its use or adoption -- the AL_BYTE_RW_OFFSETS_SOFT macro has
the same value as AL_SOURCE_RADIUS from AL_EXT_SOURCE_RADIUS (0x1031),
and since they can both be passed to alGetSourcefv, that makes it
impossible to properly support both extensions. So I'll probably have to
drop AL_SOFT_buffer_samples (and AL_SOFT_buffer_sub_data) to support
AL_EXT_SOURCE_RADIUS, and make a diifferent AL_SOFT_buffer_samples2 or
AL_EXT_buffer_samples extension that has unique enum values. But
unfortunately I still haven't gotten a response from Ryan (icculus)
about write access to the extension registry, to avoid enum clashes like
More information about the openal