When to consider double (64 bit) floating point for Audio

Question

When synthesizing and processing audio on modern processors, when would one consider using something other than single precision (32 bit) floating point? Obviously, the audio coming in and going out to the real world is 16/24 bit, so I'm just talking about the precision of the signals (both the audio itself and things like filter coefficients) in the software.

Assume that:

• the CPU/DSP has hardware floating point support for both single and double precision
• The priority is quality audio, not high performance. For example, double precision would be considered if it offered better (perceptual) quality.

Answer 1

IEEE 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.

Answer 2

You need to know the numerical requirements of your algorithm and choose the precision accordingly.

So let's do the math here: A 32-bit floating point has a 24 bit mantissa and an 8 bit exponent. This gives you about 150 dB signal to noise ratio over a dynamic range of about 1540 dB. That's plenty for most things audio. Double precision gives you roughly twice as much.

Each algorithm has certain requirements for numerical precision. If properly designed all audio algorithms that I know of do just a fine with 32-bit floating point. "properly designed" is the keyword here. For example a 6th order band pass from 40-200 Hz sampled at 44.1kHz implemented as a direct from II IIR bi-quad filter will indeed have some noise problems at 32-bit. However it works perfectly fine as transposed form II or direct form I filter.

If you attempt a partial fraction expansion of the same band pass filter using for example Matlab's residuez() function, you will get bad results even with double precision. Again the numerical requirements of the algorithm for that specific input data exceed what double precision has to offer. The key to fixing this is not to blindly up the precision, but to use a better algorithm instead.

Finally let's take a look at what makes floating (32 bit or 64 bit) vulnerable: You have enormous dynamic range, i.e. you can scale down the signal by 200dB, amplify by 500dB, reduce again by 300dB and you end up exactly where you started with almost no loss in precision whatsoever. So that's not it. Floating point has trouble adding numbers that are vastly different in size. There is a point where adding a small number just doesn't make any difference, i.e. you get 1 + dx =1. This number "dx" is about 1.2e-7 for 32-bit floating point and 2.2e-16 for 64 bit. If you algorithm includes adding or subtracting numbers that are that far apart in magnitude, you may run into problems.

A good example for this is the Direct Form II filter mentioned earlier: The direct From II filter (see e.g. https://ccrma.stanford.edu/~jos/fp/Direct_Form_II.html) basically computes the state variables by filtering the input with the pole-only transfer function first and then filtering with the zeros to create the output. Now if the poles are close to the unit circle, the pole-only transfer function gets very, very large. So the state variable can be much bigger than the input (80db to 100dB bigger) and summing state variables with the input creates a lot of noise.

The solution here is to go to a transposed Form II or direct Form I filter. Analysis shows that the state variables cannot be bigger than input/output then maybe 12dB or thereabouts, so the problem magnitude mismatch doesn't occur in the first place.

Answer 3

the CPU/DSP has hardware floating point support for both single and double precision.

It really depends on what kind of support you are talking about. On x86, when using the x87 style floating point instructions, you get the full 80-bit internal precision and the same processing time - whether you are working with single or double precision.

But when using the SIMD instructions, you can get twice more work done using 32-bit floats than 64-bit floats. That's a big deal.

Another thing to take into account is memory - using double precision divides by two the amount of data that fits in the fastest levels of cache memory.

When synthesizing and processing audio on modern processors,

It will come down to what kind of synthesizing and processing you do. If it involves IIR filters (or more generally anything with state variables and/or feedback), you can more easily shoot yourself in the foot (instabilities or low-cutoff inaccuracies due to coefficient truncation) with 32-bit, if you don't think too much about what you are doing. Some filter topologies work flawlessly with 32-bit.

In any case, it's a numerical precision issue - in terms of quality, there won't be any perceptual difference. Keep in mind that it is quite ridiculous to expect a hardware audio chain to have more than 20 bits of precision (assuming the board is impeccably routed and all parts are ideal, we're still running into the limit of Johnson noise!) - and this precision is largely covered by single-precision floats. The signal path on a high-end mixing desk has 50s of op-amps, which individually have several orders of magnitude more distortion than the quantization noise of arithmetic operations on single-precision floats.

Answer 4

If you're working with synthesised audio that undergoes a lot of processing between generation and rendering (conversion to 16/24 bit integer), then you'll benefit from working in the best numerical precision your machine has.

It is also important to make a fundamental distinction between integers and floating point numbers. A double-precision floating point (64bit) is different from a 64bit integer, and you can even work with arbitrary-precision integers in software, depending on the software tools you use. That would be important if you had to record sounds instead of generating them (as far as I know, AD conversion always saves sampled sounds in integer format).

I cannot be totally sure about it, but if you generate your sound already in floating point, the more common artifacts most likely won't be present by definition, and you can process it with much more "audio quality". Perhaps you can even generate the sound samples only AFTER you already applied some effects to the generator itself. The only moment when you'll actually introduce any potential artifact is when you convert it for output in some integer file format, such as .WAV for example.

Actually, since most machines have a native "double" (64bit) precision nowadays, I don't see a reason to work with 32bits anymore...

Hope that helps!

Answer 5

There are two benefits to going to double precision relative to single precision: increased range and better resolution. I would be very surprised if the increased range would make any difference in your application. If it does, there's probably something wrong with your scaling.

If there is an improvement it would be in the resolution. Better resolution means less quantization noise. Unless the quantization noise is close to the same level as all of your other sources of noise, though, it probably won't make any difference. You can do some analysis of your noise and signal levels to get an idea of how much of the noise comes from quantization error, but you won't really know for sure if it will make a difference or not until you implement it with both and see if it makes a difference.