[openal] AL_FORMAT_STEREO_FLOAT32 range?
chris.kcat at gmail.com
Sat Jan 10 06:38:08 EST 2015
On 01/10/2015 01:39 AM, Adam Moss wrote:
> 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
> 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
The best place to look for extension information is Icculus' extension
Unfortunately, it doesn't explicitly specify the expected range of float
samples, though like you suggest, the usual range for float samples is
> 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.
More information about the openal