[openal] AL_FORMAT_STEREO_FLOAT32 range?

[Chris Robinson]

On 01/10/2015 01:39 AM, Adam Moss wrote:
> Hiya,
>
> In the old AL specs I don't see this question answered, and I can't find
> the AL_EXT_float32 spec specifically (perhaps because openal.org is mostly
> down).
>
> The AL-soft implementation details seems to imply that float samples should
> be in the [-1.0,1.0] range, like PulseAudio, and indeed this sounds good in
> practice.

The best place to look for extension information is Icculus' extension 
registry:
https://icculus.org/alextreg/index.php

Unfortunately, it doesn't explicitly specify the expected range of float 
samples, though like you suggest, the usual range for float samples is 
[-1.0f,+1.0f].

> But a user indicates that a hardware AL implementation (unknown - perhaps
> Creative) renders this 'annoyingly loud and screeching' and that [-0.5,0.5]
> is the correct range.

This sounds odd. Generally speaking, with floats you're usually dealing 
with a normalized range of [-1.0f,+1.0f] for signed types (e.g. audio 
samples), or [0.0f,1.0f] for unsigned (e.g. pixels). You don't usually 
use [-0.5f,+0.5f] since you can double the precision for free.

If the source's gain is set to half what it normally is (default is 1), 
does the loud screeching go away on the hardware implementation?

I wonder if this may be the result of a hardware/driver bug I once 
encountered. With DSound I found that with some hardware drivers, if you 
request a float32 format (using KSDATAFORMAT_SUBTYPE_IEEE_FLOAT and 
everything, so it's completely unambiguous) it would succeed but you 
would get an int32 format instead. Perhaps the same thing is going on 
here, where the AL driver tries to allocate a float32 buffer from the 
hardware, succeeds and fills it with float32 samples, but it gets 
interpreted as int32. And somehow, having samples between -0.5,+0.5 
doesn't distort as badly as the full -1.0,+1.0 range.