Re: [try 2] [1/3] dsound: Add support for 32-bit IEEE float buffers

[Chris Robinson]

On Wednesday, September 08, 2010 11:02:27 am Owen Rudge wrote:
> +        *(BYTE *) dst = (clamp(le32(*(const float *)src), -1, 1)) * 127 +
> 0.5;

Is it safe to call le32 on a float? Especially one that's going to be used 
more? If the system is big-endian, the float/integer will need to be in big-
endian to be processed.

I'm also not sure that the conversion math is correct. In this case, -1.0 
would get converted to -126.5 (or -32766.5, etc), instead of -128 (or -32768, 
etc). As well, I don't think the rules for converting a negative float value 
to an unsigned integer are that straight forward. I seem to recall mention 
that some systems will actually give 0 in that case.

You may have to go the long way and do something like:
float v = *(const float*)src;
if(v < -1.0f) *(__int8*)dst = -128;
if(v <  0.0f) *(__int8*)dst = v*128.0f;
if(v >  1.0f) *(__int8*)dst = 127;
if(v >= 0.0f) *(__int8*)dst = v*127.0f;

..and similarly for 16/24/32 bit.

[try 2] [1/3] dsound: Add support for 32-bit IEEE float buffers

[Owen Rudge]

On 08/09/2010 15:41, Chris Robinson wrote:
> Is it safe to call le32 on a float? Especially one that's going to be used
> more? If the system is big-endian, the float/integer will need to be in big-
> endian to be processed.

The raw data should be in a little-endian format. But you're right that 
it would probably have to be converted to big-endian to be processed, 
and then converted back to be stored.
> I'm also not sure that the conversion math is correct. In this case, -1.0
> would get converted to -126.5 (or -32766.5, etc), instead of -128 (or -32768,
> etc). As well, I don't think the rules for converting a negative float value
> to an unsigned integer are that straight forward. I seem to recall mention
> that some systems will actually give 0 in that case.

I realise now that I actually made a mistake in using WORD, DWORD, etc, 
as - with the exception of 8-bit audio - all of the destination buffers 
are signed. So hopefully we shouldn't have an issue with negative values 
being multiplied incorrectly.

I'll have a poke around and produce a revised patch.

Cheers,

-- 
Owen Rudge
http://www.owenrudge.net/