<div dir="ltr"><div><div><div><div>Thanks for the reply!<br></div>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...?).<br></div>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.<br></div>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.<br>Cheers,<br></div>--Adam<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 10 January 2015 at 11:38, Chris Robinson <span dir="ltr"><<a href="mailto:chris.kcat@gmail.com" target="_blank">chris.kcat@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 01/10/2015 01:39 AM, Adam Moss wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hiya,<br>
<br>
In the old AL specs I don't see this question answered, and I can't find<br>
the AL_EXT_float32 spec specifically (perhaps because <a href="http://openal.org" target="_blank">openal.org</a> is mostly<br>
down).<br>
<br>
The AL-soft implementation details seems to imply that float samples should<br>
be in the [-1.0,1.0] range, like PulseAudio, and indeed this sounds good in<br>
practice.<br>
</blockquote>
<br></span>
The best place to look for extension information is Icculus' extension registry:<br>
<a href="https://icculus.org/alextreg/index.php" target="_blank">https://icculus.org/alextreg/<u></u>index.php</a><br>
<br>
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].<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But a user indicates that a hardware AL implementation (unknown - perhaps<br>
Creative) renders this 'annoyingly loud and screeching' and that [-0.5,0.5]<br>
is the correct range.<br>
</blockquote>
<br></span>
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.<br>
<br>
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?<br>
<br>
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_<u></u>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.<br>
______________________________<u></u>_________________<br>
openal mailing list<br>
<a href="mailto:openal@openal.org" target="_blank">openal@openal.org</a><br>
<a href="http://openal.org/mailman/listinfo/openal" target="_blank">http://openal.org/mailman/<u></u>listinfo/openal</a><br>
</blockquote></div><br></div>