DSP code - when to use floats or when to use doubles

[Dave_p]

Final production is typically 16-bit, but for internal DSP calculations, does anyone have any insight into quality versus processing time when using doubles instead of floats?

It's my understanding SIMD and vector processing prefer using floaters.

[BertKoor]

Old thread: viewtopic.php?t=468645

16bit int? That was in the last century (or only the last step: burn to CD). The buffers with audio exchanged by most all plugin formats is defined by standards as 32bit or even 64bit floating point format.

[rafa1981]

It's a per-case thing. It might be better for floats as in halving memory consumption and being able to reduce cache traffic, being able to run things in parallel with SIMD or it might be better for double as e.g. for running a stereo filter with data dependencies where the speed is basically the same but the numeric precision is increased.

Very hard to give generic advice.

[Dave_p]

Old thread: viewtopic.php?t=468645

16bit int? That was in the last century (or only the last step: burn to CD). The buffers with audio exchanged by most all plugin formats is defined by standards as 32bit or even 64bit floating point format.

Ah, my question isn't so much on if the implementation will add crackling as linked in the topic, but if there is a noticeable audio improvement, and if there is a noticeable processing collective price.

Previously, I'd always floated, but I'm considering doubling now....

[camsr]

It's better to use doubles when you have an addition of 2 signals. That also applies to the accumulation (or integration, whatever you prefer to call it) in feedback loops. However performance concerns versus perceived loss of fidelity could be the final decision point.

[dmbaer]

The extra decimal places in double precision are down maybe 140 dB from what single precision provides (if I calculated correctly), so I think you'd have to have a pretty extreme situation to come anywhere close to benefiting from use of double precision. 140 dB would be a *hell of a lot* of round-off error.

If this reasoning is flaky, please feel free to correct me.

[FigBug]

Just use floats by default. Use doubles where you need them, sometimes filter coefficients. Maybe a summing bus.

[kerfuffle]

Just use doubles by default. Use floats when you have a speed problem.

[dmbaer]

The extra decimal places in double precision are down maybe 140 dB from what single precision provides (if I calculated correctly), so I think you'd have to have a pretty extreme situation to come anywhere close to benefiting from use of double precision. 140 dB would be a *hell of a lot* of round-off error.

If this reasoning is flaky, please feel free to correct me.

Let me present this another way. In float we have a 23-bit Mantissa. Anything 60 dB down from the current sound level is inaudible, so only the first 10 bits of the mantissa matter. The first bit is about 60 dB above the 11th bit - each bit being 6 dB greater than the following one. Errors in the low 13 bits are of no matter since the cannot be heard. Again, that would be a *hell of a lot* of round-off error.

I'm curious to know if there's a flaw in this reasoning?

[Dave_p]

The extra decimal places in double precision are down maybe 140 dB from what single precision provides (if I calculated correctly), so I think you'd have to have a pretty extreme situation to come anywhere close to benefiting from use of double precision. 140 dB would be a *hell of a lot* of round-off error.

If this reasoning is flaky, please feel free to correct me.

Ah, just put two and two together. That is the most logical argument I've seen yet.

But one thought that comes to mind is with calculations that accumulate, so a number of small rounding errors, albeit it at 140db, add up to something noticeable...

[rafa1981]

Let me present this another way. In float we have a 23-bit Mantissa. Anything 60 dB down from the current sound level is inaudible, so only the first 10 bits of the mantissa matter. The first bit is about 60 dB above the 11th bit - each bit being 6 dB greater than the following one. Errors in the low 13 bits are of no matter since the cannot be heard. Again, that would be a *hell of a lot* of round-off error.

I'm curious to know if there's a flaw in this reasoning?

The flaw is that DSP are math formulas.The math calculation results need not to be in the dynamic range of human hearing.

Example: a formula that has powers of e.g. 20 both in the numerator and denominator. The result could be in the audio dynamic range if the magnitudes cancel out, but the intermediate variables for the computation need not to be.

Some algorithms are subject to precision issues, others aren't.

[hugoderwolf]

My rule of thumb is: if you find you need doubles for your algorithm to work es expected, there's likely some math that can and should be rearranged (avoid some of those "two numbers very close to 1" problems, or use a different filter structure) so you don't have to rely on double precision.

[mystran]

Final production is typically 16-bit, but for internal DSP calculations, does anyone have any insight into quality versus processing time when using doubles instead of floats?

16-bit integers are good for one thing: storing your final master or other audio that's been carefully controlled for dynamic range.

24-bit integers are typically adequate for storing temporary files.

For processing, you need more, so the question is whether you should prefer single precision floats over 32-bit fixed point, or double precision floats over 64-bit fixed point... and the answer is usually that relative precision is more important than absolute precision and floats win. There's also the consideration that on modern "desktop" architectures, processing in floats is typically faster than processing in fixed point.

There are some cases for fixed-point in specialized algorithms where you either need predictable rounding or you're mostly just accesing memory (in which case working in fixed-point can save you a few conversions between integers and floats), but for most of it there's really no point using fixed point unless you're stuck on a platform without a fast floating point unit.

[declassified]

float has the advantage that you can process twice as many at once using SIMD. For example, ARM NEON has 4 floats at once (float32x4_t), but only 2 doubles at once (float64x2_t).

One case where I definitely needed double was for Nigel Redmon style envelopes. With very long attack/decay/release times and only single-precision float, the envelope can get stuck on the same value because the per-sample diff is too low.

[mystran]

One case where I definitely needed double was for Nigel Redmon style envelopes. With very long attack/decay/release times and only single-precision float, the envelope can get stuck on the same value because the per-sample diff is too low.

Yeah, very low frequency recursive computations can run into some problems with floats. This can also be the case with DC blockers if you try to push the cutoff very low and certain reverb designs where the decay comes from repeated multiplication with numbers very close to one.

I don't think I've ever found the need to use doubles for envelopes specifically, but then again I usually cap them at something like 10 seconds anyway, which is still usually fine in singles.