64 bit audio?


#1

Any plans to include 64-bit float capability?

I’m getting some good sounds out of 32-bit, but distortion and reverb tend to accentuate the rounding errors, and more subtle effects sound grainy on close inspection.

Dave Heinemann


#2

Oh no, not one of those “I can hear the difference between 64 and 32 bit” people… :wink:

Which bit of the audio code are you talking about? The i/o or the signal-processing bits?


#3

The difference is mostly noticed in reverb tails and with distortion. No I can’t hear the difference between 0.75 and 0.7500000000001! Not without some feedback.

IO and AudioSampleBuffer are what I was after. AudioSampleBuffer is easy enough to hack on my own, but upstream from that I’m not sure how involved it is.

I might give it a spin, but also I didn’t want to waste the effort mucking around with it if you had it on the to do list anyway.

I just make everything with typedefs and templates so it’s easily portable from that end, and I get about 0% speed difference between float and double (using double internally).

Then there’s always the chance that finer detail will expose more flaws!


#4

So you’ve got a 64-bit sound card? Are there any such things? I can sort of see the argument for doing your internal processing with 64 bits (if you’re using effect chains or algorithms that feed back a lot), but as soon as it hits an output you’re straight down to 24 bits, so there’s really no point worrying about the i/o not being 64 bit.


#5

Sorry I meant the host, not hardware. 64 bit host, doing process double.


#6

Oh, for a plugin? I see. Not many hosts and formats can support that yet, though. Does the latest VSTSDK do 64 bit?


#7

VST2.4 has processDoubleReplacing.

I’m using Sonar 6, which does have a completely 64 bit signal path. No it’s not twice as good, but a little less rough around the edges.

Like I said, reverb tails, heavy compression or anything that magnifies the quieter parts of the signal or adds a bunch of quiet samples together. Great for mastering quality and for using a bunch of effects together.

If other hosts aren’t doing 64, it’s not worthwhile to make any huge changes.

I’ll give it a try. If it’s just a couple lines (canProcessDouble = true and declaring a process double function) that might be worth putting in, but it could always be more compl- uh, FUN…

Dave Heinemann


#8

The sound? Slightly better - if you told me it was 36 bits I’d believe it. Subtle with a capital B.

Implementing it? Not as hard as I first thought - just a canProcessDouble, processDoubleReplacing, AudioSampleBuffer64 and a few defines, and making sure my existing code could handle it.

The shocker? It’s FASTER.

I would have expected the same speed or a hair slower, but it’s significantly faster. Identical code except for #define AudioFloat and #define JuceAudioBuffer.

With multiple instances in debug mode I’m getting high 20’s CPU usage with 32-bit, low 20’s and high teens with 64-bit. That’s debug mode, presumably with equal overhead for both, suggesting a possibly huge difference in release mode.

VCExpress, Pentium 4 3.0 lonely core.

I’m doing analog modeling, and the sound difference is mainly in the quirks; the hiss when there’s too much distortion, the sizzle in the reverb tail on cymbals.

Of course I’ll do further testing - release mode, as well as making sure the host doesn’t have stupid amounts of overhead for converting to and from 32-bit - that should be about instantaneous, but you know hosts…

I also want to check if it’s worth converting incoming 32-bit signals to 64, processing , then converting back to 32, even with a less elaborate processing chain (my major project has 6 different effects, part of the reason I’m so glad for an improvement in speed and detail).

And I though “double” just meant precision…

Dave Heinemann


#9