Under what circumstances is it important to represent and process samples double precision floating point representation (versus single precision)?

arguably it isn't ever 'important' with the samples. The added precision is essentially inaudable, but comforting to know it's there.

It's a good idea with coefficients, especially with filters expressed in Direct Form 2, or with cut-offs close to 0 or PI. unless you've written your own software FP routines, you'll most likely be using the x87 stack which does everything 80bit internally, so actual calculations are always super precise, it's only in storage of values that precision is lost. SSE, as I recall, does calculations at only the bitdepth specified, rather than using a wider format internally (I could be wrong).

Does that help any?

Not really

What about a scenario involving digital audio workstation software, and the application of many effects in the pipeline to multi-channel data? Is there a case where double precision samples will preserve intermediate calculations that might have been lost to quantization error otherwise? For example, when applying a compressor effect?

it might make sense in a modular host i guess
..if you're able to make feedback loops between the plugins..

I get the feeling one of these days we will have a math coprocessor for bcd datatypes. Problems solved, almost.

already exists actually. the main processor does (edit: actually hilarious so i'll leave it in:) BPD and has a whole slew of opcodes

double as a transport? hm... never. normalize your signals before conversion to single and you'll never, ever, ever, ever, ever, ever see a problem.

ever.
Last edited by aciddose on Sat Feb 18, 2012 4:48 pm; edited 1 time in total

never ever?

nope.

LIke I say, filter coeffs (and memories), yes perhaps, but the number differences are in denormal land (I went there on holiday as a child - the rides were slow and awkward)

*heavy sarcasm alert*

Some companies believe that telling their customers it's double precision, makes them hear it as 'better' through powers of suggestion.
So you'd better use the magical 128 bit processing, at 192Khz.

As you increase the order of a filter you may find that you either require higher precision calculations, or anothor solution such as breaking it down to biquads.

remember we're talking about normalized audio signals here, so no, never ever

float gives you at least 24 bits. that's 140db+!

in calculation you might need more. blah blah, all kinds of exceptions. none of those are regarding normalized audio transport though.

When the laws of physics change and reduce thermal noise (the unavoidable low-level noise of any sound playback equipment) to a level requiring more than 24 bit signals.

NASA landed on the the moon with 15 bits accuracy, hehe have fun researching that.

Are you going to record the samples? If so, with what? The noise floor certainly drops off as you get right up on absolute zero, but I'm just not sure how you're going to manage that recording session...

So, are you going to calculate the samples? OK, you can do that, but what are you going to play them back on?

Single precision floating point gives you 25-bit of precision (23-bit mantissa, one implied bit due to normalization, and a sign bit). That's 150.5 dB. If your output is 1 V p-p, the least significant bit would be, what, less than a tenth of a microvolt? What do you think the background (thermal) noise of your gear is?

Sure, there are reasons to do double precision math (high-order IIR filters, where small errors in coefficients and calculations in the feedback can become large, for instance). There's always a way around needing double precision, but the bottom line is that double precision is usually next to free (most processors already work in double precision), though it can be costly if you're going to store everything in double-precision.

Plus, it sound really good to some people to hear, "The audio signal path is 64-bit from input to output, for maximum resolution and headroom", "...delivers the sonic purity and headroom of a true 64-bit, floating-point digital audio path", "...'s 64-bit asynchronous audio engine with industry leading audio fidelity, 64-bit audio effects and synths, the forthcoming...which provides native 64-bit ReWire integration, allow for an end-to-end 64-bit audio path". Yeah, I did a search and pulled those marketing quotes from real products. What happens when a software maker starts touting extended precision 80-bit floating point (not nearly-free)? Will everyone rush to 80-bit?



Plus, I'm sure that the issue of a workstation's (and plug-ins') support of 64-bit (memory addressing) operating system adds a layer of confusion to some people.

BTW, this topic made me look up some references, such as an article explaining why 64-bit is a good idea. All of the arguments I've seen use flawed logic, showing a misunderstand of the math—such as explaining the range of 64 bits as 2 to the 24th power, and saying it helps guard again overflow (hello, it's floating point...). Another said that 64-bit floating point might not even be enough for a clean sound, because there's the problem of thermal noise (!!!).

actually, that is true.