Ah, yes. I mixed up those a bit although I know the difference in theory.
It’s the kind of considerations mentioned below quoted from a dsp forum I was curious of regarding Juce. That is, if I set an
AudioBuffer<double>, am I guaranteed all processing will be at least in double precision in any Juce module as of Juce 6? Since the old
AudioSampleBuffer was equal to
AudioBuffer<float> I was thinking there might be conversions or truncations from
float sometimes in older modules.
EEE float singles only provide about 24 bits of mantissa. But many DSP/filtering algorithms (IIR biquads with poles/zeros near the unit circle, etc.) require far more than 24 bits of mantissa for intermediate computational products (accumulators, etc.), just to get final results accurate to near 16 or 24 bits. For these types of algorithms, 32, 40 and 48-bit scaled integer accumulators were often used with DSPs that had no FPU.
But on many current processor implementations (for PCs, smartphones, etc.), the double precision FPU is far faster than trying to use 32 or 64 bit scaled integer when your algorithm needs to have more than 24 bits of intermediate product.
To prevent trashing the data cache, the raw data can be in short integer or single precision float format, while only the more local computational kernel might use a higher resolution format. But if you are sharing intermediate computation results between DSP modules, the interchange protocol between modules may also benefit from a higher resolution (more than 24-bit mantissa) bus or data format.