On Fri, Oct 14, 2005 at 09:00:37PM +0200, [EMAIL PROTECTED] 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
