14 Oct
2005
14 Oct
'05
6:53 p.m.
On Fri, Oct 14, 2005 at 09:00:37PM +0200, cpolymeris(a)gmx.net wrote:
I just don't fully understand the floating-point
precission part. If numbers
from binary 0.1 to 1.0 are represented using 24 bits (sign bit + mantissa, I
think the implicit 1 does not count),
It does.
and the numbers from binary 0.01 to
0.1 also have 24 bits of precision, and so on for 0.001..0.01, etc. wouldn't
that mean we have a higher resolution?
Only for small signal values, so not really. Don't assume that small signals
are centered around zero - they usually are not. Using floating point only
means you have to worry less about absolute levels during the processing.
Then I also fail to see why it's bad for overflows
to ocurr in fixed point.
Those signals (above 0dB FS) would clip on the hardware anyway, and are
expected to do so, since they were either badly recorded or amplified.
They may be clipped on the hardware IFF you give the hardware more bits than
it actually uses, otherwise the hardware just can't know if they have to be
clipped or not. But normally you just can't do that, so don't count on automatic
clipping. Worse, unless you are using some specialised DSP chips that can do
clipping in the ALU, implementing clipping in fixed point software usually leads
to an immense waste of processing power. And if you use fixed point and do not have
any provision for clipping, then any overflows will result in very high amplitude
spikes that are really excellent for destroying your speakers, in particar the HF
parts.
The bottom line is really quite simple: if your app is to run on a PC, use floats.
There are some very good reasons why floats were chosen as JACK's default audio
type.
On the other hand, don't count on FP or even double precision to make for example
marginally stable IIR filters stable. Sometimes it works. Sometimes it appears to
work but your filter (or rather your speakers) may still explode for some inputs.
--
FA