[openal] AL_FORMAT_STEREO_FLOAT32 range?
c at yotes.com
Sat Jan 10 12:31:41 EST 2015
Thanks for the reply!
I have a touch more info from the user: the hardware is Creative Audigy 2,
and the AL implementation they're using is the system one, definitely not
AL-soft, most likely the Creative OAL (are they still shipping that...?).
It does sound like a driver bug; even if that driver were expecting a
-0.5,+0.5 range it'd seem a bit mad for the output, saturated or not, to
sound 'screeching' rather than simply loud and clipped at worst.
I'll see if the user is in a position to build with a patch so I can see if
the half-volume source or some other workaround might work.
On 10 January 2015 at 11:38, Chris Robinson <chris.kcat at gmail.com> wrote:
> 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
>> The AL-soft implementation details seems to imply that float samples
>> be in the [-1.0,1.0] range, like PulseAudio, and indeed this sounds good
> 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
>> 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.
> openal mailing list
> openal at openal.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openal