DAWbench - Reference Benchmarks :.


PC DAW O.S Shootout : Part III : XP 32 v XP x64 v Vista 64 - SONAR :.


Back again ..

Part II focused on the Performance of SONAR 6.2 in XP32 and Vista64, using both x86 and x64 versions across the respective O.S's. The performance under Vista 64 was disappointing to say the least , and suggested that there were some other mitigating factors other than the performance variables attributed purely to the different O.S's.

It was confirmed that we had inadvertently used a bundled plugin that did not have a Native x64 version , the Vintage Channel - VC64 was in fact only 32 bit - Go figure, a plugin called VC-64 is not x64 native ? - , this of course skewed the results due to the introduction of the performance penalties imposed by the BitBridge , so we set out to redo the Test session with only plugin's that had both confirmed x86/x64 versions.

What is a Bitbridge ?    

BitBridge is essentially a 32 bit extension, or wrapper, within a native 64 bit application that allows you to incorporate 32-bit instruments and plug-ins into the 64-bit realm.

BitBridge is the term that Cakewalk have coined, while other company's like Steinberg for example will no doubt use another term for essentially the exact same thing.


The importance of the BitBridge for those navigating across to a X64 O.S is that it will allow the transition to be as smooth as possible using their existing 32 Bit PlugIns/ VSTi's until all the above are ported to x64 Native.

Its definitely serves that purpose well, however the performance penalties it imposes can vary from mild to wild depending on the number of plugins that are requiring to utilize the Bridge


Of course in our test session where there are enormous amounts of plugins being initiated , by inadvertently selecting a plugin that utilized the BitBridge as the one used to apply progressive load , we had crippled the performance on the X64 testing , without realizing it at the time.. :-(

It was time to ditch the Bitbridge

Revising the Test Session - Goodbye BitBridge :.    

After we had confirmed that in fact the VC-64 was the culprit, again with the help of some members over at the Cakewalk Forum, I set about revising the session , this time ensuring that we used only plugins that have both x86 and x64 versions.

It was definitely an interesting exercise working thru each bundled plugin , and discovering exactly which plugins didn't have x64 variations- at this point I would like to thank Eratu from the Cakewalk Forum for going above and beyond in sorting that for me - granted there were only a few, but of course it just happened that we had selected one of those few in the first session.


The original Test session was then revised , replacing the VC-64 Vintage Channels with Sonitus Multiband Compressors, and also eliminating some other plugins that were not x64 compatible.

The Test session was then Beta tested by a small group to ensure that in fact the Bitbridge had been eliminated from the equation.

Once we were confident that we were clear of the Bitbridge we starting testing again


This time around, it was requested that I re-introduce XP x64 into the the testing cycle, as well as also testing SONAR x86 on the X64 O.S's, to ensure that we had covered as many bases as possible.

So with the Bitbridge out of the equation, and with the 3 O.S's that I had used in the initial testing of the 32 Bit Steinberg Apps, I cranked the trusty Intel Quadcore test system back into gear , and let fly.

The results were interesting to say the least.



Round 1 : SONAR 6.2.1 : Lynx 2 /RME : XP32 v XP x64 v Vista64 : ASIO :.

Despite the above graph only showing the Lynx results, I did in fact cross reference the results between both the RME and Lynx cards used in the previous round - just to get that variable out of the way from the get go.

As in my previous results with R1 , the results between the 2 cards is within 1-2 plugins across both XP and Vista, so we maintained good consistency with the previous benchmark.

Initially I was not interested in exploring SONAR x86 on Vista x64, simply because it defeated the purpose of the exercise , which was to have a direct comparison of a Native x86 application on XP32 , and a native x64 application running under Vista x64 - the O.S that the application is touted as being developed and optimized for.


However after further discussion with the members over at the Cakewalk Forum, I decided to dust off my XP x64 partition, and run the tests across the O.S, to have a direct comparison to the newer X64 O.S.

The performance delta across the 3 O.S using the x86 version of SONAR is negligible on this test , however the results using x64 version of SONAR on the appropriate x64 O.S's show a distinct loss of performance , even with the bitbridge eliminated out of the equation.

Lets put this into perspective., both Steini and Cakewalk 32 bit app's showed a performance hit using XPx64 and Vista x64 over XP32, but the performance hit was not really tangible until we got into the lower latencies below 128 , however , using the X64 native SONAR version, we are already seeing a 25% hit at 256, and a 75% at 128.


Behavior under Vista 64 was smoother this time, but the results are still way below what I was expecting with the BitBridge eliminated out of the equation.

So this definitely raises the question on what exactly is going on.

We have now eliminated the Bitbridge as the variable , which leaves the combination of the X64 Application / x64 O.S

The other thing that is highlighted here is that the much touted Multimedia Class Scheduler Service optimization has not amounting to anything past hyperbole.. Surprise .. :-(


Round 2 : SONAR 6.2.1 : Lynx 2 : XP32 v XP x64 v Vista64 : WDM :.    

So onto WDM, clearing a few hours one arvo to run some numbers up, inadvertently turned into a few more hours than I had planned. Some interesting results, and also some ongoing and infuriating issues I encountered by having both SONAR x64 and x86 installed on XPx64 and Vista64..

My initial testing in XP x64 with WDM on SONAR X64 was disastrous , resulting in crashing anytime I attempted to load a plugin - same error every time, crash caused by ntdll.dll. I tried different versions of the Lynx driver to no avail, I uninstalled SONAR x86, etc, etc, No Cigar.

Moving right along.., I let that breath for a while, and moved to Vista 64, and to my horror encountered the identical crash in SONAR x64 in Vista as well - in both R1 and R2 of the SONARbench. Now I was getting angry. I had run a whole stack of benches on SONAR x64/WDM previously, so I knew this behavior had been introduced only since testing SONAR x86 on the x64 O.S's.

I needed to remove all instances of SONAR , reinstalled just SONAR x64 from scratch, and repatched to 6.2/6.2.1 and we were back in business.., for want of a better word.


I managed to get the results on Vista, and then returned to XP x64, but this time I decided to blow the whole install away, and reload my original optimized image, and reinstall SONAR X64 only.., and also hopefully get to 6.2.1, which had been a problem on the earlier test run.

On the fresh image of XP x64, I reinstalled SONAR x64 and repatched 6.2/6.2.1 without a hitch this time, no stalling on the C++ component I suffered from on the initial run. I then ran thru the tests and got the results..

Man,. what an adventure, and not something I am interested in revisiting again any time soon.

Firstly, I only have results for the 256(5.8) and 128 (2.9) settings on the Lynx, as the Lynx card would not profile correctly below 128 sample buffer setting, as I had reported in my first round of testing , I didn't cross reference with the RME this time, simply because I still had not resolved the issue with the RME WDM driver that I had experienced on the first round. To be honest I haven't placed a priority on it..


The interesting thing is that the results @ 256 for both the X86 and X64 versions of SONAR using WDM under both XPx64 and Vista64 were close enough to par, unlike on ASIO where there was a large delta. It didn't hold steady tho, at 128 it went south again unfortunately.

I am yet to witness any of the much touted performance advantages on X64 / Vista .

After arm wrestling these app's across XP32 , XP x64 and Vista 64 for the last few weeks, I can honestly say that by far the smoothest experience is still XP32. Also , installing both the x64 version and x86 versions on the same O.S, whether it was XP x64 or Vista64 definitely thru some gremlins into the mix.

I know there are going to be punters hopping on board saying that they have no issue running both version on the same O.S, but I can only voice what I experienced, and it wasn't pleasant .., it felt like there was some major cross referencing crap going on under the hood when both are installed.

Conclusion :

This rounds off this final batch of testing until the next generation of Cakewalk and Steinberg app's make their appearance over the following few months.

I will then revisit the 3 O.S's , and be testing both x86 and x64 Native versions of the respective applications

This exercise has definitely addressed a lot of areas in regards to the constantly evolving 64 Bit DAW landscape , as well as the inevitable transition to Vista and beyond.


It has also opened up a few areas of discussion in regards to the claims of Cakewalks in respect to x64, and the much publicized performance advantage that a Native x64 application on the appropriate O.S would bring.

Prior to this project, we really didn't have much in the way of being able to quantify any of the claims presented, and these results although not conclusive, give a far better, more accessible and quantifiable platform to continue the investigation in future.


So in closing, I am still of the opinion , that there is no real advantage for the vast majority to be going anywhere near Vista for audio application, and the x64 transition is not going to be as swift as first hoped.., so again , sounding like a broken record.., I wouldn't be touching Vista until all applications / plugins are ported natively across..

Vin Curigliano
AAVIM Technology

Part I, Part II


© AAVIMT 2007