Neither Aero nor MMCSS are able to get more than 100% out of a PC, they only help to overcome culprits/issues that may occur. Aero can help versus bad GUI coding and when using more than one GUI drawing application at once. MMCSS can help versus background processes getting in the way (like Aero/DWM). It can bring its own problems as well, hence it's a "compromise".

In the case of Aero it's usefulness also depends on how much of Windows you are using. When you're only working inside your DAW application it doesn't make much of a difference. But if you are using the PC for other stuff there are some workflow enhancements that go beyond the eye-candy, like previews of sub-windows when you hover the mouse-pointer over the task-bar icon of a running application.

And there is one more thing: current graphic-drivers cannot use classic hardware acceleration methods for 2D elements anymore since Vista. This leads to current premium GPUs drawing 2D lines and circles slower than 10-15 years older ones, which in turn can mean more CPU load for the application drawing that stuff when Aero/DWM isn't taking over that job (using proper current methods of acceleration). Not much to worry about with our DAWs that mostly only use bitmaps, but you may use your PC for other stuff, too...

Does Nuendo turn the whole Windows desktop to Basic then? If not then it doesn't make any difference. Just because it doesn't use Aero style elements doesn't mean that it doesn't use Aero/DWM.

It was fixed with sub-version 7.0.12 (no mentioning in any changelogs). Now Live's main problem remains to be the large discrepancy between fixed realtime priority and using its default (where its GUI gets in the way of audio/midi). Other applications suffer from this as well, but usually to a lesser extend.

I usually measure full CPU load via Task-Manager and Process Explorer. CPU load indicators inside DAW applications are just that, indications. What they don't measure for instance (neither on Windows nor on OS X) is system/kernel load created by taxing the audio, midi and graphic subsystems. In the end all that matters is, how many tracks/effects can I get and how effectively can I utilize my CPU towards its maximum load (I paid for that thing, so I want to use it to full extend).

Because they're either ignorant or just badly informed by their support department (and I know they can handle MMCSS because they once implemented a workaround for turning off MMCSS in the RME driver), fear to give full non MMCSS realtime control to Live (knowing how instable it currently is) or Marketing tells them to leave this for the next *paid* update. And generally they are likely overworked and may also have lost track of the code-base (Gerhard Behles mentioned something in that direction in a video presentation for Live 7).

Hey Timur,

Of course it can't extend the performance of a system that is already running well close to 100%, which mine are with Basic, hence my point that it isn't really any advantage to me personally in DAW use.

Understood , but my only focus is Professional DAW use, I really couldn't care less about application outside of this area.

I know of the reported 2D issue with the current O.S's/drivers, but I really haven't experienced any issues with the Quadro NVS Workstation class cards that I primarily use in Win7, perhaps because their focus is 2D efficiency more so than 3D , and no, you can't run games on them.


No it doesn't shift the desktop, but if its using Aero for its elements, why are the elements being displayed as Basic ? You may well be right that is still using Aero/DWM, doesn't negate the fact its doing SFA... LOL

Correct, and its why I developed this methodology in the first place, Meters for me are absolutely of no relevance past an indicator, a prime example is when breakup occurs at say 50% ASIO load , but TM could well be idling at 30%, waste of time trying to measure scalability via meters IMO.


Sounds like Ground Hog Day to me, you can pretty much insert an devs name in there..... LOL

Quick heads up,

With this info being specifically related to the PT9 roll out last week I thought that I would start a separate thread in the PT9 Native sub forum to try and keep the commentary more focused , I created a thread called PT9 v Cubendo v Reaper v StudioOne : Cross Platform Performance : and on trying to post the thread was shown a message that informed me that all threads in that area needed to pass moderators approval before it could be posted. Now seeing the absolute garbage that was posted in that area , I didn't think for one second that the information that I was providing would in any way be open to censorship, but its been 2 full days and that thread hasn't appeared in the sub form, so obviously someone has deemed it unworthy for some reason.

Why ?

Read On.

Hey All,

I was just rounding off a whole stack of cross platform testing with PTLE/MP 8.04 when AVID unleashed the new PT9 with instant download availability, which was perfect timing to dot the i's and cross the t's.

My main interest, as would be for many others not locked into the Digi/AVID hardware circle , is how well PT9 performed using open hardware. My reference hardware for all my non AVIDesign testing is RME HDSPe , so being able to use that hardware natively is the game changer.

O.K The results..

First off with the M-Audio Interface which was the hardware platform I was doing the M-Powered testing on.



Results and overall feel for PT9 and PT8MP on Win7 were identical, and I do mean identical, which makes me very suspicious what the actual driver protocol is being used , overall PT9 behaved exactly the same as M-Powered, except now we had ADC. On OSX, PT9 was measurably better than PTMP 8.x

As you can see from the above results, PT swept the floor on OSX and the comparative cross platform performance is a lot better than the other DAW's, except from that one weird anomaly with the MD5 @ 064 on OSX .. ??

The RME results..



Well just when I thought I was heading for a slam dunk..., check out the Win7 results on PT9 @ 128 and above on the Channel Strip Pro and Elysia mPressor , I swear I thought I had entered the Twilight Zone... LOL

The 032/064 results on CSP had me floored, easily way better than any of the other competing DAW's across the board , but @128 Buffer those 2 test sessions went decidedly askew, the 032/064 sessions would not load @ 128, it was ugly to be honest, meters pegged in the red, GUI crawling, I was like WTF. So I dropped back to 032 samples and reopened the saved sessions, and sure enough they both played fine, they were right on the edge as expected, but they played back perfectly. Moved to 064 samples, opened the 032 sessions , no problem, opened the 064 sessions, no problem. At that point I was seriously scratching my head what was going on @128.

Not exactly sure what to make of it yet, and I doubt I'll be getting any response out of AVID while they are in their honeymoon bliss during AES, but I'll stay on it and see if I can get some response over the following week(s)

Something definitely not right when you can get better performance @ 032 than you can @ 256.

Which leads to me to this,

Who BETA tested this with 3rd party hardware, and how did they miss this ?

The above behaviour does open up some bizarre scenarios where someone working at 064 samples for example, gets close to the edge and wants to move up the buffer settings to get some more headroom, will in fact have the negative effect, or even better yet, someone working at 128 buffer, will have better performance by dropping to 032.. ?? !!

As a follow up , I ran some test on an RME Fireface 800 today to see if the issue I experienced on the RME HDSPe card was reproducible on the Firewire units as well. The lowest acceptable buffer for the Fireface 800 on Win7 is 064 , as PT9 will not accept the 048 buffer setting. I ran up and fully loaded one of the test sessions that was displaying the issue previously, using the URS Channel Strip Pro , and sure enough , the 064 session would not load @128 or 256. The variable isn't as big as the HDSPe, 133 CSP's at 064, 128 CSP's @ 128 and again 128 CSP's @256 - it did not scale at all from 128 to 256 this time.

Something screwy there.

Early days yet , definitely a promising start, but some ASIO bugs to iron out.

Before anyone asks why I haven't posted this at DUC yet , easy , I would rather not have to deal with admin from the parent company controlling the information flow.., and it seems that this information has also some disapproval @ Gearslutz. I may still place the helmet on and run the gauntlet at DUC , but I'll tread some water for a few days first and see if anyone else is reporting any quirkiness with other hardware..

Vin, you're an absolute saint for doing all of this for all of us, and for free!

it would be great if you could run these tests with PT 9 HD Native, with the new Native PCI-E card as the interface.

i'm very interested in it's performance on Win 7 x64.

but i will understand if you can't. them dingalings don't come cheap!

all the best,

Hey Richie,

Yeh, the performance of new PTHD Native PCIe card , in PT9 and via ASIO/CoreAudio - is something that I and many others will be interested in , I'm sure.

I'm currently waiting on a PTHD Native test rig , no ETA ATM, but I'll post all the of the details once I have put it thru its paces... warts and all.. :-)

FWIW: I posted my findings over at DUC, and it has met with pretty much deathly silence so far, except one member asking me if I tested at 512 and 1024

I informed him that I haven't tested a native DAW at 512 since 2005 , and it still doesn't negate that there is a problem.

I don't get it.. , maybe I am making too much of this?

excellent, i await your further results with great anticipation.

and no, i don't think that you're making too much of this very odd behaviour. it needs to be explained and fixed by AVID asap.

TAFKAT, kudos to you for doing all this. thumbsup

I' m thinking of moving from OSX to Win7 and your tests are definitely informative and helpful.

so basically besides 1 plugin discrepancy pt9 is the closest osx vs win of any cross platform app to date. interesting.

i always said pro tools ran ok on mac!

interesting indeed and bodes well for the native version.One question though, are you using RTAS versions of the plugins in pro tools vs VST on say Cubase/Reaper?

I always thought RTAS was a very poor format especially under windows with regards to low latency and multi thread scaling.


MC

Hey M,

Yes RTAS in PT, VST in all the others tested so far, Protools will not be going to VST/AU anytime soon if ever from what I can make out.

I think the whole RTAS /Windows thing may have been FUD started by some that have never really tested them side by side, and we all bought it, me included to be honest.

I was under that exact impression myself until I ran thru these test sessions , and it was a real awakening just how well all of the test plugins did against the VST driven apps. The OSX RTAS results were an even bigger surprise , where they actually outperform Windows in some instances, and were a lot closer comparatively with Windows than the other DAW's as well.

I keep hearing that the real variable in RTAS v VST/AU is in the Virtual Instruments, so I'll see how that pans out when I get to the VI version of my test session using NI Kontakt Free, so that everyone else can play along as well.

@ TNM,

The performance with PT9 on OSX v Windows varies depending on the plugin, which is interesting in itself , but over all its way better than the other DAW's. The only other app with the potential is Reaper, they just need to sort that loop glitch, ohhhh, which reminds me, I need to get back to Justin re helping to sort that quirk..

Too much on..

BTW: I haven't forgotten do the extra testing on that plugin list you gave me, I'll get to it when I can :-)

well that's good new for pro tools users indeed. I am very surprised,as I'm sure are others as to how well Pro tools 9 seems to be working under windows.I bought MPowered years ago so I could have basic pro tools if I needed in the studio, and to be honest it ran like a dog under windows,but great on OSX.

I've personally been using Reaperx64 now 100% on my projects and under windows x64 it's a joy to work with, iI can't imagine going back to an x86 DAW :D

THanks for the great work Vin,

MC

Hey MC,

PT has always been very solid on OSX, but I have also had good success with both LE and MP and even HD on Windows as well, but have never really done any serious head to head up until now. PT on Windows 7 x64 took a while to sort "officially" , MP was actually running well @ 8.03 , I couldn't even get LE to run prior to 8.04, but since then it had been pretty smooth - within its limits of course.

I hear ya , I think Reaper is a fantastic application, and the dev team are above and beyond. The workflow/ feature set isn't for everyone of course, but I have a lot of time for all involved there, and I am sure V4 will continue to improve.

Hi, how can this be done?



Im new here and recently purchased a yamaha n12 using cubase, but i have a big problem, my asio meter in cubase overloads depeding on my project while my cpu is only at 25%, i am running a i7, with hyper threading on, dpc latency is 16 -19, i have experimented with buffer size, but for example, can the delay compensation become so great that the asio simple dies?

could any one verify by using a few plugs that induce alot of delay into there chain and see if they can get there cpu to hit as high as they normally can, or would the added delay from eg mastering plugs , fx etc simply drive the asio to overload without reaching a cpu count.???



so im curious why and how can i some how use up more of my cpu as it can take alot more yet, the asio meter craps out on me.

any input would be appreciated.

thanks

Tweaking MMSCC isn't going to resolve anything for you IMO.

What specific plugins are you using with inherent delays that are causing the PDC calcs and high ASIO load ?

How many of them are you using, and how ?

hi, thanks for the reply.

plugs such as a combination of slate fgx, a few soundtoys plugs, urs strip, fab filter plugs, izotope, and a few synths etc


for example, if i create a new project, 1 audio track, and load up 3 slate fgx's (i know its not meant to be used as such) my asio meter clips and simply dies, while my cpu is only at 15%.

so can the delay caused by the worst offenders make the asio crap out?

is the total amount of latency caused by plugins directly effected to how hard your asio meter is driven???

We need to clarify whether its actually a plugin or whether its simply a badly written ASIO driver.

Seeing you have the URS channel strip , you can actually download and run my DAWbench DSP session that I used in the recent testing and do a quick comparison to the results I achieved with the RME. I know thats not a fair comparison, but it will give us a better idea if the actual driver for the N12 is tanking. I also have results with an M-Audio Profire 610 that I am about to upload, so that will at least give us some pointers.

Download the benchmark Here

Nuendo5 / URS CSP / i7 / RME results below : They will be close enough to par with C5.5



Let us know how you go.

My suspicion is the N12 drivers are , hmmmmm, less than ideal.. :-)

ok i will try the test and report my results shortly.

Ok ,

First my DPC latency


Now your test under 32 samples

68 plugs , cpu was not hit much, any more and the sound started to deteriorate, asio meter was ok but sound was cracky.




Now 64 samples
which went alot better, 141 plugs, no breaks in sound and allowed to loop several times to hear for any abnormalities




Now 128

now my cpu really takes a hit and i presumme i am coming to a bottleneck of my system

184 plugins no break up in sound at all




moving on to 256 not much of a differnce, actually the worst performace gain of just a single plug

185





after that i tried with my highest buffer settings, but only got 3 more plugs on 2048 not worth me posting images for that.

So according to my results how does it affect my theory of if you have many plugs that induce huge delays, does it hit the asio as a detrimental effect?

as a 15% cpu hit and the asio crapping out is not good at all.



Notes
im using cubase 5.1, if its not broke why fix it, and personally i didnt like the gui changes of the latest update, so i reverted back on my main machine.

all wifi, lan cards etc disabled, btu i am using a microsoft wireless mouse and keyboard with dongle.

O.K,

System seems to be scaling O.K, I did notice the N12 has double buffers on output which explains some of the higher plugin counts @ the upper settings.

I am noticing more drivers are resorting to that lately ... :-(

I digress,

Channel Strip Pro doesn't have any inherent latency, so this first test was just to see if the driver was O.K.

Some plugins with large inherent latency and higher demainds on read ahead buffer i.e linear phase EQ's, convolution verbs - will hit the ASIO harder, but the behaviour is not consistent and the amount depends on the actual plugin, so try and pinpoint which is causing the highest hit.

You can check the actual amount of delay in the plugin list.

If ASIO is tapping out with only 15% TM loadings , there are other factors involved, you just need to narrow down what the culprit is.

What latency setting are you normally using ?

BTW: You actually loaded the plugins in the test session incorrectly, the correct method is to do it horizontally , not vertically . i.e, insert one, sine track 1-40, then insert 2 - track 1-40 , etc. It doesn't really matter too much in this instance, but it does incrementally load more evenly when doing it horizontally.

BTW: Can you please reduce the size of the screen caps to max 750/800 pixel , so that the forum formatting returns to normal.

Thanks

that's interesting and why i wanted to see how cubase handles plugins with LARGE delays at low buffers... logic, samp etc get away with it cause of the hybrid engine, but if i would have to switch cubase to 1024 at mixing stage to handle these sorts of plugs (which it can do now even on mac at that high buffer), then i'd rather just stay hybrid.

hi many thanks, looks like i have to go through my projects and see which plugins cause the asio meter to crap out.

regarding the screen caps, i just uploaded them to image shack and not sure how to edit the sizes so i deleted the big screen shots,

but regarding the test results i did achieve, are these sub standard results? or is my system configured ok?

all test were done on my main studio computer (i7)


also has there been any tests on daws regarding the max amount of plugin induced delay on each daw, before the asio hits its peak?

is there any tool we can use as a plugin in a daw, to induce a big latency to see what the bottle neck for each daw is,

as i presumme, there must be one, regarding my experience with a 15% cpu usage yet asio meter is overloaded.

That would be helpful.

Try GIMP , which is an open source replacement for Photoshop , very cool for those that don't have P.S.

As I noted earlier, system seems to be scaling fine.., out of interest , what clock speed is the system running at ?

Each DAW's PDC/ADC is different , also the plugins that have the larger delays usually have an intended use for Mastering ( convo verbs being the exception ) , but are used outside of that intended use as channel or group inserts , so we would need to weigh up how exactly we would test for the break point that would be relative to how end users would experience it.

A quick empirical test wouldn't be too hard, stacking a plugin with high inherent delay vertically will incrementally increase the PDC/ADC. We would need to decide where that plugin would be stacked tho, channel, group, master, send ? ADC/PDC would not really apply as much on a send tho.

Also, inherent delay is not the only variable involved , i.e, Steinbergs Multiband Compressor that I use the Cubendo DSP version of the test in the dowloaded suite, has higher inherent delay than say REVerance , but REVerance has a far higher CPU loading and also does not scale as well incrementally.

We need to pinpoint which of the plugin(s) in your session is causing the abnormal loading, and work from there.

I'll clear some time this morning and do some testing at my end with some of the other plugs listed by TNM, and see what they throw up as well.

TNM,

Managed to run up the rest of that list of plugs for you.

DDMF LP10: Linear Phase Mastering EQ : Inherent Delay : 12,288 Samples :

Used on Master Bus :

032/128 ASIO is erratic even with one instance, needed to go to 256 to clear playback. Mind you the actual ASIO load was under 10% with faint flickering, clip light was on tho.

TM : is about 5-7%

Voxengo Elephant in 8 x Oversampling : Inherent Delay : 959 Samples

Used on Master Bus :

032 - 2 Instances each with about 25% ASIO accumulative per instance , 3rd causes breakup.

064 - 4 instances each @ 20% ASIO accumulative per instance / 5th cause breakup.

TM never got higher than 10-15%

Melda Linear Phase Auto Equalizer : Inherent Delay : 32,768 Samples.

Used on Master Bus :

032/064 - similar behaviour to LP10 - ASIO is erratic even with one instance, actual ASIO load under 10% with faint flickering, clip light was on .

Clear playback @ 128 - ASIO under 5% / TM about the same .

The plugins with the larger latencies did not really disproportionally increase the ASIO load as such, they where just very erratic at the lower latencies, the plugin that actually munched the ASIO disproportionally was the Voxegano Elephant, which had the lowest latency out the tested plugins, but the highest ASIO overhead . So we need to be clear on that, having high latency does not necessarily mean higher ASIO load, another example is the Steinberg MBC which has 1712 samples delay, but minuscule ASIO overheads.

We do need to also note that all of these listed plugins are specifically for Mastering , not really used for tracking / mixing , so YMMV , personally I would not have an issue with these specific plugins in say a Mastering application like Wavelab. In Cubendo as long as they are used at that Mastering stage they are usable , but the whole application responsiveness goes to shite with those huge delay across the Master Bus , even when the buffer setting @ 128/256, so definitely a no go for tracking / mixing.

Look like Logic may still be your better option.. :-)

Just a quick one to swing this back to the cross platform performance testing.

I have uploaded the latest cross platform DAW performance reports, this time focusing on Protools / RTAS / DAE and of course ASIO/CoreAudio / RME with Protools 9.

Parts IV / V can be found Here

Updated charts using the RME HDSPe now including PT9

Interesting indeed

It does seem like AVID have got the cross platform thing very well sorted with PT9 and also it seems to perform very well on both platforms compared to the other Native DAW's


I think from personal experience using reaper x64 that when using lots of Audio tracks and VSTI's, the performance and stability boost in using an x64 program is something to be taken into account too when thinking about overall DAW real world usage,hence my last post about not considering pro tools 9 as there doesn't seem to be any x64 road map.

All food for thought though and competition is healthy between the companies, as it's us, the end user that will benefit from the gains made.

MC

WOW thanks so much Vin and yep this has confirmed my every suspicion....

The thing is logic is handling these better even if i set S1 or C5 to 1024 buffer in OSX to match logic's "cheat" hybrid playback... oh well.. thanks..

the mauto equalizer is indespensible to me even in mixing as its my secret weapon for creating space. I do like to use the LP10 now and again too, not just for mastering... seems like my question is answered, logic, and mac.

Thanks again

On OS X Logic (8) is less susceptible to Speedstep than Ableton Live. Would be interesting to know how much Nuendo/Cubase, Reaper and Studio One are affected.

AVID definitely seem to have it covered better than the others at the moment, it will be interesting how they respond , or if they do at all.

The application that has the most potential to go toe to toe with PT9 cross pltform is Reaper, just gotta get that loop glitch sorted .. :-)

Hey T,

No problem Mate.

It was an interesting exercise for me, learned a lot in how some of these plugs can still easily collapse these native DAW's.

Keep powering with Logic Bro..

Sorry Mate, not following you.

Are you talking specifically on OSX/MAC EFI hardware ?

Speedstep is not in the equation on any of these tests, it has been completely disabled at the BIOS level. I should add its a non issue even on my audio notebooks with Windows 7 , despite not being able to be disabled at BIOS level.

The issues with Speedstep are very specific to OSX / EFI, its a non event for anyone else.

Well, one could assume that part of your readers who are interested in OS X performance of the tested DAWs *are* using Mac/EFI hardware.

That was my point as well.