64-bit double precision for the plugin-interface

[BlueprintInc]

I don't get it. Process your plugin in 32 or 64bit like you want to and copy the result into buffer like it is done since forever. Getting a 64bit buffer by the DAW doesn't mean you have to use it and "waste" your resources. We process our plugins with double precision anyways and I'm happy the VST interface provides a double precision buffer to transfer these results back instead of cropping them.

I also don't get what the DAC fuzz is about. I'd say a DAW does a bit more than a DAC

[Vokbuz]

"waste" your resources

The funny thing is that processing 64-bit floats may be faster. So it is not necessarily a "waste".

[Guillaume Piolat]

I don't think it's very useful to exchange samples between plugins and host in 64-bit.

The theoretical 120dB of dynamic range mentionned above in the ear should be barely realized in practice.
The litterature is more speaking about a 100dB range for the ear, and less range outside of the 1000 to 4000 Hz area. It's already an amazing feat.

Even with doing that all day I've been hard-pressed to A/B a RMS difference of about -90dB, that difference was already microscopic and I doubt going further is worth it.

Of course, _some_ processing inside a plug-in really needs the precision (for when the errors add up), but not all.

[BlueprintInc]

"waste" your resources

The funny thing is that processing 64-bit floats may be faster. So it is not necessarily a "waste".

That's why I set it in quotes, it were Markus' words. I don't think it's a waste either (that's why we use 64bit internally as a standard) and I noticed more optimized and balanced code in certain areas.

[Markus Krause]

I take my time to properly optimize my software. In many of my synths i use integer for the oscillators, floats fot the filters and doubles only where it is necessary and where it makes sense , like for pitch calculations and modulation. I also do many polynomial approximations. This allows me to create software that offers high sound quality with low demands on the cpu.

When you claim that 'double is as fast as float' you ignore some important facts:

- divisions with doubles are slower
- the memory-bandwith of double is only half as fast as float. And memory is really slow compared to the registers
- you need twice as much RAM
- many library functions like sqrt, sin or pow are a lot slower with double than sqrtf, sinf or powf
- The cache of the CPU is limited. With doubles it doesn't work as effective as with floats. The cache has huge impact on the performance

These are the tricks and advices that i can give you as a full-time dsp-developer with 25 years of experience.
In the end only you decide how you code your software

[BlueprintInc]

- divisions with doubles are slower

I'd say generalized claim that doesn't keep emulation of floats/doubles in mind or CPU architectures. Modern CPUs can handle float & double at the same speed (CPU cycles).

- the memory-bandwith of double is only half as fast as float. And memory is really slow compared to the registers
- you need twice as much RAM

Sure, for audio buffers. Don't know how many there are in a common plugin, but I'm sure this is not a bottleneck as there's more memory used by help texts, parameters, graphics and whatsoever.

I'd rather take that point and map it to vectorization where the width of doubles make you need twice as much operations compared to float. That's a valid point. If it makes that big of a difference is arguable - at least for usual plugins.

- many library functions like sqrt, sin or pow are a lot slower with double than sqrtf, sinf or powf

Given only if you use them. I mean who of those who optimized their code really uses sin, tan or whatever from like the standard library and not at least some performant approximation?

- The cache of the CPU is limited. With doubles it doesn't work as effective as with floats. The cache has huge impact on the performance

Given only that you do not alredy use any cache optimizations (like layouting data or certain slicing).

These are the tricks and advices that i can give you as a full-time dsp-developer with 25 years of experience.

I don't get why you have to tell that in nearly every thread. No disrespect, I know some of your work and surely like some of it. But I mean to me it just doesn't matter if the content a users posts is questionable.

But again all that is great and such, but the topic of passing data to the interface via 32 or 64bit buffers is completely different and all written has no impact on this. Why a DAW uses 64bit does not impact the behaviour of your plugin the slightest. Go ahead, copy the data into a float buffer and process it. I think if the DAW uses 64bit anyways like for summing purposes or reduced noise floor, it's the best to pass that precise buffer to the plugin as well and not purpously trim precision. And I also think that a plugin then should process it that way.

Offtopic but it's similar for samplerates: having plugins reducing the samplerate for performance makes me angry. Take what you get and do your stuff with it.

[Markus Krause]

You are right. We got off-topic from the initial post.
i started this thread because i got annoyed by Steinbergs 'snake oil' advertising for Cubase 9.5 that 64 bit buffers would be a real game changer. This is not honest towards customers and it is not honest towards developers

Reference:
https://helpcenter.steinberg.de/hc/en-u ... processing

[BlueprintInc]

I btw. agree with you on that! Given the VST2 and VST3 interfaces provide the processing of double precision buffers for years and that it has been used already by DAWs or internally by plugins, it's advertised as innovative. Quiet funny the article says "Double precision processing is not available for VST2 plug-ins!" which I can't understand and is inconsistent. One thing I hate the Steinberg DAWs for.

[Vokbuz]

which I can't understand and is inconsistent

This statement may refer Cubase capabilities, not plugin format capabilities.

[rafa1981]

If every plugin were passed a 32 bit buffer and wanted to operate internally at 64 bit, they would need to allocate own buffers, so the chances of "touching" more memory and trashing the cache could maybe get higher.

Not for synths or reverbs, but I guess that having some processes operate in place on the passed buffer can maybe offset the advantages of the lowered bandwith. When reaper introduced 64 bit processing in the Win XP ages it was still the fastest.

There is not much memory waste IMO in this DAW case IMO, as we are fortunately talking of very low memory requirements. When a good DAW calculates the DAG (e.g. REAPER) is going to try to reuse the same buffer for every graph branch all the time (and processing in incrementing memory addresses). Considering that a big process buffer is 512 samples, the difference is 2kB vs 4kB for each used channel (float vs double). For 64 branches/paths (channels) the total amount of buffering required would be 128KB vs 256KB. Everything fitting on L1. If things were in RAM then DAWs wouldn't reach 1/10 part of the speed they reach.

[MFSAKA]

64 bit double precision engine not first about headroom!
It's about precise processing. Amazing resolution for any type of processing.
Google what it is first, before start a bummer.

[mystran]

Yes. Passing audio around in buffers holding 64-bit floats makes the sound about 4294967296 times better than what you can get with 32-bit floats.