The interesting thing is on Intel X86 CPU's there is no significant difference computationally between 32 bit floats vs 64 bit double precision, since they use 80 bit registers for both types. IIRC they take the same number of clock cycles to process a float instruction. There is however a huge gain over integer arithmetic including fixed point math which is much slower. So for most software implementations its a no brainer to use either float or double precision. There is a very slight performance hit with double over 32 bit float when you consider the memory footprint since we're pushing twice the amount of data on the bus, and some potential cache issues. 
 
We switched to supporting 64 bit floats in 2003-2004 when we ported the app to a 64 bit architecture - besides the extra precision, it was the most logical thing to do. It had nothing to do with DirectX or anything like that. We could have done 64 bit in DirectX if we had chosen to do so at the time. It just turned out that the 64 bit revolution started around the time we decided to stop using DX in our engine.
There is no question that 64 bit gives you higher precision and is virtually lossless in terms of errors. Whether the extra accuracy is benefits a typical mix or is audible is obviously a loaded question depending on many factors as discussed in this thread already.

So there you have it....
 



 
 

Goddard

D K
 ^^^ Game, Set, Match ^^^ - That is.. for anyone whose primary concern is about performing,capturing, mixing and presenting...music

 
Seeing as how you feel compelled for some reason to keep score here, why don't you instead tell us all about how much improvement your heard in your Tango 24 after shelling out for that BLA mod?
 
Btw, we'll be expecting objective proof...

Son.. do you really think I give a rats A** about proving to you (or anyone else for that matter) what improvements BLA did or did not make to my Tango 24?
 
Stick to posting unread links and mindnumbing pointless internet arguments... and just for relevance sake.. I'm betting my 20+ years of experience doing this.. that BLA's modification to my Frontier Designs Tango 24 did a metric ***t ton more for improving sound than whether or not I have checked the 64 bit engine box in my preferences..
 
I'll wait for the new link about metric tons....

drewfx1

Goddard
Still, noteworthy that the processed 16-bit streams always nulled, even when using floats, whereas the 24-bit streams never nulled when floats were used. Hmm, maybe double precision does matter. Good to hear the bug's been squashed.

 
You crack me up. 
 
You just can't seem to comprehend the difference between an error being present and being audible or meaningful. Until you will admit that those are not the same thing, I will not waste anymore of my time on you.
 
But I will wish you good luck in your future endeavors.

Ha! And I didn't even put a smiley after my "Hmm, maybe double precision does matter" remark! (although obviously floats are not really "double precision" wrt 16-bit PCM, only "higher precision")
 
Be careful while you're cracking up that you don't fall off your high horse!
 
I comprehend the difference just fine, thank you. Have for a long time now. The question of the necessity vel non for double (or extended or, at least, higher than source) precision when performing dsp operations is hardly a new one. Been there, learned and practiced that already back when dedicated fixed point dsp was pretty much the only option, although some chips could also implement floating point, and things only became more critical as converters got better and  higher resolution formats like 20- and 24-bit and became more widely used. Fun times, experimenting with what other tricks could be coaxed out of the Moto 56K on a TB Tahiti.
 
So yes, I am very well able to comprehend (and mostly still hear) at just what point rounding/truncation errors may become so significant as to be meaningful. Just as I am well able to comprehend how and why rounding errors which may occur in stream data but not be significant enough to be audible/meaningful may in the course of downstream processing be compounded to such a degree as to become definitely audible in effect and undesirably manifest quite meaningfully above the relevant noise floor, as well as what measures may prevent or at least ameliorate such, including the use of higher processing precision. So yes I already grokked what these are all about:
 
http://www.jamminpower.com/PDF/48-bit%20Audio.pdf
 
 
http://www.analog.com/en/content/relationship_data_word_size_dynamic_range/fca.html#4
 
(although, were I say, coding today for a native host-based DAW or DSP application, I might also look at the merit of implementing Kahan summation rather than relying upon naive)...
 
http://baumdevblog.blogspot.kr/2010/11/fast-kahan-summation-implementation-in.html
 
Anyway, it's been fun but as my time is becoming rather precious just now and it's apparent you're more interested in arguing about what is or isn't audible, perhaps your own time might better be spent arguing with Craig instead about "fuzziness" and "fizzing" and reverb tails:
 
http://www.harmonycentral.com/t5/Craig-Anderton-s-Sound-Studio/64-bit-sound-Are-you-using-it/m-p/36059653/highlight/true#M277140
 
or with Bob Katz about what a double precision digital mixer sounds like:
 
http://www.digido.com/articles-and-demos12/13-bob-katz/17-more-bits-please.html
 
as they seem to be able to hear things, and Bob's real big on null tests too.
 
 
Btw, even award-winning "null test" results which get published by AES can be off:
 
http://www.cirmmt.org/activities/newsletter/past/april2012
 
https://secure.aes.org/forum/pubs/ebriefs/?elib=16597
 
http://www.aes.org/e-lib/browse.cfm?elib=16518
 
oops...

Anderton

Goddard

Anderton

lawp
so the dpe is/was just marketing hype?

 
As I've said before...when the 64-bit engine was introduced, the world of audio engines was quite different and it was a major step forward.
 
Please note this is my personal opinion and does not speak for Cakewalk.

Craig, with all respect (and I've been enjoying your writings since Polyphony and Device days), "double precision" DAW audio engines had already been around for some time before Sonar's DPE. SAW used 64-bit processing (running native on PC), and Digi used 48-bit/56-bit DSP chips for PT TDM (with 24-bit paths between chips?) giving effective double precision (or at least, the necessary extended precision for accumulation when mixing 24-bit audio).

According to the SAW site, the last version of SAW released in 2001 had a 24-bit audio engine. Pro Tools had a 48-bit fixed engine but bottlenecked to 24 bits when going through the TDM bus.

Can't recall at what version it began but SAW definitely was implementing 64-bit precision from way back. It might have even been a mixture of 64-bit integer for some processing (mixing?) and 64-bit floating point for other processing (FX?). Definitely from the time when it became capable of handling 24-bit audio. I don't think it was ever much promoted as 64-bit processing at the time, just as a "24-bit hard disk recording engine". There was an epic online argument back when between the two Bobs (Lentini and Katz) over truncation and dithering (which SAW originally lacked).
 
The DSP chips (Moto 56K) in PT's TDM engine could in fact send 48-bit data over the bus by using two TDM timeslots.
 
Sonic Solutions also offered an extended/double precision DSP-chipped DAW back then too (Studio?), for DVD audio production.

Noel Borthwick [Cakewalk]
The interesting thing is on Intel X86 CPU's there is no significant difference computationally between 32 bit floats vs 64 bit double precision, since they use 80 bit registers for both types. IIRC they take the same number of clock cycles to process a float instruction. There is however a huge gain over integer arithmetic including fixed point math which is much slower. So for most software implementations its a no brainer to use either float or double precision. There is a very slight performance hit with double over 32 bit float when you consider the memory footprint since we're pushing twice the amount of data on the bus, and some potential cache issues. 
 
We switched to supporting 64 bit floats in 2003-2004 when we ported the app to a 64 bit architecture - besides the extra precision, it was the most logical thing to do. It had nothing to do with DirectX or anything like that. We could have done 64 bit in DirectX if we had chosen to do so at the time. It just turned out that the 64 bit revolution started around the time we decided to stop using DX in our engine.
There is no question that 64 bit gives you higher precision and is virtually lossless in terms of errors. Whether the extra accuracy is benefits a typical mix or is audible is obviously a loaded question depending on many factors as discussed in this thread already.

Ah, thanks for explaining all that, Noel.
 
I recall being surprised by the performance benchmark results given in that white paper at the time of the 64-bit rollout. I had the impression that SSE2 and x64 might have been a stimulus.
 
Anyhow, in the interest of precision (just in case you weren't aware):
 
http://baumdevblog.blogspot.kr/2010/11/fast-kahan-summation-implementation-in.html
 
http://baumdevblog.blogspot.kr/2010/11/high-precision-floating-point.html
 
 

X3D now out - Your issue is finally resolved. Please shake hands and have a game of tennis.

BTW now my 64 bit engine is back, I completely agree, it sounds so much better. I'm actually busy decoding the differences by listening to my tracks several times, so far I detected 45 buzzes or so, came out in morse as "let me out".... not sure what that is about.... I'm amazed I didn't hear it the first time...