[openal] Format clarification

[Chris Robinson]

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[1] 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 
that again.


[1] <http://kcat.strangesoft.net/openal-extensions/SOFT_buffer_samples.txt>