Subject: [linux-audio-dev] Re: floats vs. ints
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: pe loka 15 1999 - 14:15:32 EDT
>> In message <87zoxljw0v.fsf_AT_flophouse.localnet>you write:
>>
>> my main reason is the cost on the Pentium of converting back and
>> forth. but i have also read compelling arguments on why
>> float makes sense over on the Csound mailing list.
>
>Can you summarize?
the most compelling ones seem to me to be:
1)
short sample_buffer_1[1024];
short sample_buffer_2[1024];
short output_buffer[1024];
... fill sample_buffer_1 with extremely loud noise ...
... fill sample_buffer_2 with extremely loud noise ...
... mix sample_buffer_{1,2} into output_buffer ...
In this scenario, you will either have to accept clipping or do
soft-limit (logarithmic) truncation like Apogee or use an
intermediate representation (float?) for every sample of every
buffer pair at every place where two of them are mixed
together. If you use float as the buffer type, you can basically
forget about it: you have close to infinite headroom for all
practical purposes.
2) on contemporary CPU's, float arithmetic is normally faster than integer.
3) a variant on (1): consider a plugin/function that does various
multiplicative transforms on its data before compressing it all
back down to a reasonable dynamic range. this can only be done
safely with float, so why introduce yet another int16<->float
requirement ?
4) audio generation/processing often makes heavy use of trig functions
and other math library stuff, all of which require floating point
arguments. if you want to know sin(x), why make the compiler do
yet another int16->float->int16 conversion, when you could just
make x a float ? a similar situation applies to any sample
processing involving division, which can unnaturally truncate the
result if done with integers.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:59 EST