[openal] AL_FORMAT_STEREO_FLOAT32 range?

[Adam Moss]

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.
Cheers,
--Adam

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:
>
>> 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.
> _______________________________________________
> openal mailing list
> openal at openal.org
> http://openal.org/mailman/listinfo/openal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openal.org/pipermail/openal/attachments/20150110/aad25aaf/attachment.html>