Hey All,

This thread is a continuation of my work that was detailed in my other thread here - i7 Nehalem Hyperthreading in DAW Performance , I have decided to start a new thread as the focus has shifted significantly from the original thread and I thought it better to start fresh.

The initial thread started out as an investigation of the cross platform performance of the Steinberg products and the area of Hyperthreading , it has expanded to include testing across numerous other DAW applications.

The focus will remain on cross platform DAW applications - the current testing pool includes Cubendo ( Cubase/Nuendo), Protools, Reaper and StudioOne , the reference plugin list includes the WaveArts MD5 ( which has been one of my reference plugins for many years) , URS Channel Strip Pro and Elysia mPressor. The expanded list of 3rd party plugins was included to level the playing field across all of the applications , the operating systems and the differing plugin formats.



First up I needed to round off the Steinberg specific test to compare the Nuendo 4 to Nuendo 5 to quantify the highly publicised multiprocessor and low latency improvements in N5, and then compare those results to the other DAW applications most similar to the Steinberg product, that being Reaper and StudioOne

This is the worksheet of all the results across the 4 applications on Windows 7 x64 and OSX 10.6.2.

This was a huge undertaking as each latency run was 28 test passes ( 14 each for Win7 / OSX) , and thats not counting going back and rerunning some test to double check the results. I have completed a few reports based on the above data that are now uploaded at the DAWbench website Here

In short Nuendo 5 does not deliver any performance advantage worth talking about over Nuendo 4 on either OSX or Win7 on the current i7/i9 systems. In some cases it was worse depending on the plugin. Both StudioOne and Reaper also performed substantially better on Win7 over OSX , so the performance variable is not reserved to Cubendo , but what is not evident in the results is that Reaper was light years ahead of both Nuendo and StudioOne on OSX at the ultra low latencies, but had a slight glitch at the loop point, so I backed off the plugins until I cleared that glitch - I could have easily loaded another 15-20 plugins in some instances as the playback was crystal clear apart from the loop glitch. So in short Justin is on to something in regards to scaling on OSX that the other guys haven't quite worked out yet.

There is definitely a lot to absorb, but if you have a closer look at the MD5 results on OSX, you will see @256 that they are not far off Win7 on N4/N5 , also N4 does measurably better with all the 3rd party plugs than N5, which is an eye opener. The plugs with the inherent delay which need the PDC/ADC calcs - the MBC and EMP do significantly worse on OSX than say the 2 plugs without any inherent delay - MD5/CMP. Thats not immediately obvious , so its something that I have noted in the reports.

The other thing is just how much better Win7 feels when pushing the sessions to the limits , OSX just has this underlying feeling of being close to the edge all the time. Mind you it did get ugly on Win7 right at the top end of these tests - ASIO/CPU meters pegged and I mean pegged 100 % , GUI slowing to a crawl, navigation almost non existent, but the playback was still clean. Incredible actually just how well all the apps scaled on Win7. Each had their specific quirks when taken to the limits, Nuendo and Reaper were a little less ugly at those points, StudioOne was getting very- hmmmm, cranky, and you will notice that after a good start on OSX, pretty much fell in a heap even worse than Nuendo.

The 3rd party plugins were all great in regards to stability as well.

Also StudioOne on OSX had some added quirks in regards to loading / saving sessions , activations expiring, etc,

I am talking to Justin over at Cockos to get that OSX loop glitch sorted in Reaper, its the exact same issue we had on Windows a few years back and is related to its read ahead buffering. Justin made some adjustments on Windows which resolved it, so if he can do the same on OSX, the results will be significantly better and make a mockery of the other 2 apps. Its really close now.

The Protools LE /MP RTAS testing is next, but I freaked out when I discovered you can't have both LE and MP on the same O.S install, PITA, which means I had to do all the testing in LE with my 002 , then test one or a few of the other apps as a cross reference using the same hardware/ASIO/CoreAudio driver, then uninstall LE, install MP and use an M-Audio interface , etc.

One last note - All results are with Hyperthreading ON, there are no Hyperthreading OFF results this time around, simply because after close to 2 years and countless hours of testing , with volumes of empirical data showing that in the vast majority of cases it is in fact beneficial to have Hyperthreading ON.

I am not willing to waste any more time arm wrestling the powers at be at Steinberg over their continuing stance that it is in some way preferable to have it OFF.

More to come , I am just rounding off the PT testing over the next week.

Here are some graphs of the Multi App Cross Platform results taken from the work sheet above.







Check out the reports at DAWbench for the full details.

Part I - XP/Win7 x64 : OSX 10.5.8/ OSX 10.6.2 : Cubendo

Part II - Win7 x64/OSX 10.6.2 : Nuendo 4 v Nuendo 5

Part III - Win7 x64/OSX 10.6.2 : Nuendo 5 v Reaper 3.6 v StudioOne 1.5

This is great info, lots to digest! Thanks for putting in the time and trying to make the environments as close as possible for the cross platforms comparisons.

One question.. on the Windows side you're running W7 64 bit, are you running the 32 bit versions of the DAWs? And if you're running the 64 bit versions, are you running the plugins in the DAWs native bit bridges, or in jBridge?

what was the sample rate of the audio tracks in these tests? also how many audio tracks were used? and what was the speed of the hard drives? Lastly what filesystems specs were used?

thx

Great. Here comes the circus.

Tafkat thanks so much for doing these.

I have always noted that OSX falls apart at lower latencies with plugins that introduce delay and need compensation... As is finally proved by your test...

OSX just can't handle plugins like convo verbs, or large look ahead limiters, or plugins let's say like voxengo elephant at 4 or 8 x oversampling, at low latencies. Logic circumvents this problem by using it's internal 1024 buffer, or 512 in my case as i use the "small" setting.

I am also glad your graph shows just how abysmal studio one's performance is in OSX particularly at lower latencies.. it's almost impossible to use for even a medium sized project.

I downloaded reaper by coincidence last night before i read this report and as much as i still detest the layout and feel of the software, i did notice immediately how much better it handled itself on OSX.

I have a question though if you wouldn't mind answering.

I am strongly considering going back to windows and cubase 5.5..

but the times i have run this on bootcamp, even though it out performs the osx version by a margin, the cpu meter or asio meter is still incredibly erratic at low latency sound card settings with high latency plugins. The thing is, in windows 7 on bootcamp i disable core parking, and run cpu-z, and even at idle there is no throttling going on *at all* the 4 cpu's are always at 3.06ghz (they are 2.93's but i guess they are overclocked by default slightly on the motherboard)...so i am presuming i should be getting decent performance.

I have attributed this to two things: the motu ultralite windows drivers suck, and of course the mac has FW800 only which has never played nicely with windows. But i also tested an mbox 3 usb 2 and got similar results.

If i DO go back to a windows machine built from the ground up probably by yourself I am going with an rme hdspe aio.. Does PCIE suffer from the same cpu spikes at low latencies when using high latency plugins? I'd want to track at 64 and mix at 128. Is this possible? with a couple of convo verbs let's say and some high latency dynamics plugins? cause i know it's not possible for me with the motu or mbox. Thanks in advance.

I will want to run at 64 samples for tracking

Really not trying to be a prick, but was it necessary to quote the ENTIRE post?

Hey C,

All the applications and plugins are 32 bit versions.

Once the 64 Bit native arena settles on OSX, I'll do some native 64 bit head to head comparatives as well.

Hey T,

I have always had some reservations about boot camp, but I have not had enough experience with the boot camped official hardware to make a qualified analysis. The issue may be related to clocking and thermal levels controlled by the C-States that are not accessible thru the Apple EFI implementation.

I have not experienced the erratic ASIO behavior with the reference hardware that I have tested thus far, but it could be related to the MOTU audio interface. I have a variety of reference hardware here I can test with, but no MOTU unfortunately. I haven't tested the new Mbox3 as yet, but ASIO on my Digi 002 test unit under Windows 7 x64 is laughable, not only does it not work at all in Cubendo, but even in StudioOne and Reaper, 064 buffer was returning 10MS latency , 128 -14 MS and 256 - 19MS - No comment.. :-)

The test session is very easily reconfigured with any load plugin , so if you give me an idea of the specific plugin(s) that are causing the issues on your system, I can do some testing for you at my end and see if I can duplicate the behavior. We can quickly rule out whether its systematic, audio hardware or plugin related.

Re StudioOne on OSX, I was disappointed that it didn't scale consistently especially after the 032 results looked so promising. Re Reaper, yeh ,there is definitely something happening under the bonnet there that feels a lot tighter on OSX.

Hi!
Well basically i can give you some perfect examples.

Reverence being a prime one. At anything under 256 buffer on bootcamp in cubase i get the asio meter first clipping, then going wildly erratic even in an empty project with one instance. (on OSX it's a nightmare)

A second perfect example: DDMF's excellent linear phase mastering EQ, LP10

In studio one on OSX i cannot even get ONE instance of this to run without the cpu being in the red, in logic it uses 20% with no spiking, of course due to logic's internal buffer.. but it's stable.. on cubase bootcamp same thing as studio one OSX and CUbase OSX... it goes nuts...

A third example. Voxengo elephant in 8 x oversampling.

A 4th example, melda linear phase auto equalizer (even with no oversampling)

Logic handles all these with ease whereas none of the other hosts i mentioned on either platform do. That's why i was specifically wondering on a proper custom built daw pc from a professional, with a pcie rme card, if cubase can handle these plugins at low latency.

as you can see from the examples i've given it's basically plugins with large latency which cause the problem. Fully functioning demo versions are available for everything i've listed. Of course there is more, but i think that's a good starting point.

meldaproduction.com
voxengo.com
ddmf.eu

if i raise the buffer to 1024 on cubase it can handle these ok on OSX, acceptable... studio one still shits itself... logic the best of the lot.. This is why i specifically need to know how windows 7 deals with them with a good pcie card.

FWIW i'd initially plan to run cubase 5.5.1 in X32 mode but in Windows 64 professional (mind you i wonder if windows 64 professional is not the right choice? that's all i've got to test with)

Hey T,

Cool, let me work thru the listed plugins and see if I can duplicate the behaviour at my end. I do remember Reverance being problematic on its initial release, but I thought they had addressed a lot of the issues with the spiking, so I'll check again for you.

Linear EQ's and Convolution Verbs are definitely the litmus test when it comes to how the respective DAW's ADC/PDC routines/buffering cope with added inherent delays , so it will be interesting what these plugs throw up within the testing environment. I don't mind expanding the test pool if it helps us highlight what the variables could be.

Give me a few days to get some clear air and I'll drop back with some results for you.

EPIC! Much appreciated!

reverence has never worked great at very low latencies.Logic uses a standard 1024 sample buffer regardless of settings unless record armed, that's why the plugs run fine on logic.



MC

Not just reverence I am talking about. FWIW, remember i said i use logic on the 512 internal buffer. There's small (512), medium (1024), or large (2048).

On osx nothing can compete with logic even on 512. Studio one still falls on it's arse, as does cubase (quicker than logic)

OK,reverence is the only one I've experience with.Regarding latency even 512 is large by today's standard unless i use Nebula which needs larger buffers I can track and mix at 64 samples no problem, I'm on windows 7 x64 though :-)


MC

Vin, thanks for what appears to be an Herculean effort!

Not to contest your findings, but in regard to this:

Fair enough to use a purpose-built Windows machine, no problem with that.

But methinks that including Bootcamp in the test would have been not a lot of extra hassle and surely a significant and revealing addition to the test.

As it stands, this omission could easily be misinterpreted as partisanship. After all, only with Bootcamp could you get to test the two OS'es on identical hardware. (FWIW, I do not think that Win7 under Bootcamp would have taken a performance hit)

Nevertheless, thanks for all the hard work. thumbsup

I could be wrong but I think Vin did test on identical hardware by installing OSX on his machine thereby bypassing as much as possible any Apple EFI cpu throttling issues etc.

MC

correct! if anything by avoiding the Cstate stuff on a mac it would actually help OSX #s

Scott
ADK

Again, not to discredit your work but in my experience this is not always true.
My brother runs a fairly new PC with Win7 and he had serious performance issues with YellowTools Independence Pro, it just would not behave properly and was all but unusable. Looking for a possible solution he was advised to switch off hyperthreading: Problem Solved.

And I don't understand the latter part of the quote, arm-wrestling with Steinberg?

That's a little over my head, but I fail to see why Bootcamp was excluded from the test. I have no problem with testing on a Hackintosh, but I believe running the tests under Bootcamp would have added weight to the findings and would not require a lot of extra effort.

Vin's explanations as to why he chose not to do so leave me a little mystified.

because running windows 7 x64 on a Mac pro under bootcamp you still have the issues with the thermal throttling etc as it's using the mac EFI so you can't turn it off.

doing in the way he did gives an exact comparison on exactly the same hardware with maximum DAW performance.

MC

Hey Z,

As has been noted by Norbury , running a bootcamped Mac would not add any further weight unless the OSX results on the OSx86 system are in question. In Part I - I go into great detail how I ensured that the OSx86 configuration was performing as expected, if anything it actually outperformed the official hardware , a 2009 Mac Pro with double the number of CPU's on 10.5.8 and gave that same system a good run for its money under 10.6. The MacPro was a little down on Clockspeed compared to my single i7 system, but it still highlighted that it was performing extremely well.

Most of these test are public domain, I need to upload the new sessions with the URS and Elysia plugins later this week, so anyone with a Mac system with bootcamp can easily do the tests themselves. That has always been the idea that any of my reports can be qualified by anyone who takes the time and energy to do so.

Re The Hyperthreading , well I did say in my experience in the extensive testing as well as all of my clients who run a very wide variety of plugins and Virtual instruments, Hyperthreading has proved beneficial , I can't comment on the instance of the Yellowtools , that is obviously some issue with the instrument coding itself, but I would not consider that the norm.

Re my arm wrestling Steinberg over HT, hmmm, maybe read my other thread, that should fill in the gaps for you... :-)

IMO- The whole issue with HT on the i7's being detrimental to me is a red herring that devs will use to try and compensate for sloppy coding, the recent fiasco with Logic is a good example of that. If it was across the board, then maybe I would give it some weight, but when the majority of applications/plugins/virtual instruments work without issue , the onus is on the developers to get their ducks lined up, not for the end user to loose the potential benefits that HT offers.

Peace

Hey T,

Had a few minutes this morning to quickly run up REVerance in C5.5 for you on the dev system in Win7 and OSX with an RME HDSPe AIO and an M-Audio Profire 610.



Screenie is in Win7 x64 - 10 REVerances running on the RME HDSPe AIO @032 , the ASIO meter is bouncing a little , but its all playing back fine. On the M-Audio it was pretty much identical readings/behaviour @ 064 .

On OSX 10.6.2 - RME HDSPe @ 032 - ASIO meter bouncing more so than in Win7 x64, playback was a mess, @064 it was fine, the M-Audio Profire 610 was fine @064.

Not sure how many REVerenace instances will tip the system over, I'll check that at a later date, but that should give you some indication that what you are experiencing on your system needs to investigated further.

I'll check the other plugins when I get a chance

thanks, i really do appreciate this.

It's the "osx bouncing more" that's troubling and actually confirms my suspicions. It's when the instances are added, or combinations of other high latent plugins.. OSX is just useless at lower buffers.

I did try an m-audio firewire solo, i forgot about that, in bootcamp, and i believe m-audio firewire all share a common driver, and it still did bounce around in cubase on windows, but not nearly as bad as OSX.

I am convinced it has something to do with not being able to completely disable c -states etc in bootcamp, and the fact the mac uses only a fw 800 port.

My motu in osx itself, has never, ever missed a beat. solid as a rock.

the other thing of course, and the most ideal, would be a babyface for a home studio like mine... on board fx, bus powered, neat, no need to open machine.. etc.. and i believe it will perform identically driver wise to a fireface uc?

I wonder if in a dedicated windows DAW if i could leave the babyface at 128 and never have to change it.. a good overall compromise, cause i track vocals with the built in monitoring reverb directly in the hardware, whereas with a hdspe i obviously can;t do this, i need to track as low as possible. If the odd guitarist comes in which is uber rare and wants to track into an amp sim, then i wonder if the rme usb could handle that at 64 samples.

All very interesting, then there's the option of course of getting an efix chip and having a proper hackintosh with all the bad shit disabled in bios so OSX runs at full steam, and have cubase on windows also on the same machine.

I'd probably go a 980-x and just use the multiplier to overclock a bit, and get some super good ram.. twould be a nice system.

Anyway i am rambling but i appreciate the tests, but will wait of course to see what happens when a variety of highly latent plugins are introduced into cubase windows at low buffer settings.

regards, T

I've been following this one closely and I'd like to add a couple of personal experiences.

I have this session of this acoustic song with some 30 tracks of guitars and some 9 tracks of piano. The funnies experience of them all - my MacPro (dual 3.0 Harper, 14GB memory), can't playback that while my single-CPU "let's try it out dual-core Hackintosh" (tried with Core i5 650, 750, core i7 875k) can while yawning in the background. Now, these CPU's vary from dual-core with HT (650) to native quad-core without HT (750) to quadcore with HT (875K).

This leads to the following conclusions:
- many of the apps written for today's OS's aren't optimized
- many of the apps written for today's OS's don't know what HT is and how to use it efficently
- many of the apps written for today's OS's don't know what multicore is and continue going down the single-threaded route.

The problem is the fact that almost all of the applications confirm these points.

When you combine all of these three things, you get the conclusion that's a given - programmers are lazy a$$es as well as their managers and companies alltogether, to give us stuff that should've been on the market years ago. Yes, there are quite a few good examples of applications that wouldn't be able to do much with multicore support. Also, there are a lot of apps that would (encoding, rendering, and stuff like that already do). But most of them would benefit, by a lot. Bear in mind that multicore CPU's came out in 2004. And don't even get me started on the 64-bit debate.

Logic is a piece of crap software when you take a look at it from the "multi-core with or without HT" angle. It just doesn't know (without AUX tricks and stuff like that) how to use resources that it has on any given Mac or Hack. And that pisses me off on a daily basis.

@TAFKAT: Thanks for the effort.

Please rerun the Windows tests with Aero turned on/off. And if you find time rerun them with the DAW software being manually forced to "Realtime" priority via Task-Manager (needs to run TM "as Administrator").

To perform the latter you might have to do some tricks. I.e. Reaper keeps resetting its own CPU priorities whenever you perform an action. So the safest way is to start playback first, then change the priority and then don't touch anything. AFAIK Studio One should not be a problem, no idea about Nuendo/Cubase.

I ask about these, because I know that most audio application on Windows still use *non*-realtime CPU priorities which happen to be used by Aero/DWM as well.

On OS X there also is a way to change priorities, but it's a bit more complex there. I know about Ableton Live that it already uses the highest possible priority on OS X while on Windows it benefits a lot from forcing it to realtime.

@Robertshaw: Please stop quoting the *whole* original post, just to add a single paragraph below it. It demonstrates more lack of your own efforts than of Tafkat's.

This is a complex issue, even more so with the iX line of CPUs. With the Core2Duo there is a workaround/hack in OS X to turn off Speedstep completely (combination of removing OS X CPU power-saving kext and using Coolbook).

On the bootcamped Windows side the problem lies within the EFI/BIOS emulation that does not allow software to switch EIST permanently (this is the kext part of the OS X hack). You *can* manually change the clock-rate, but it keeps changing back.

One thing you need to make sure on Windows is to set it to "High Performance" mode, because that makes Windows' CPU driver increase CPU clock-rates a *lot* earlier compared to "Balanced". It also switches off the PCI power-saving option, which has a *very* definite impact on Firewire audio devices (up to causing drop-outs and BSODs with RME Firefaces). You can enforce it further by running Prime95 in the background (runs at lowest possible idle priority 0), but that will also heat up your CPU.

With OS X in combination with Firewire there is another variable. Once you plug in a Firewire device OS X seems to keep the CPU clock-rate up, which some people reported as additional heat when playing audio over FW. This has so much of an impact that Lloyd Chambers even measured slower (raid) harddrive performance of the internal SATA ports when *no* FW device is connected.

Once I get my i7 based MBP and find time I will try to hack it as well. The best source for these kind of things are Hackintosh discussions, because this scene spends a lot of effort getting power-saving features to run properly on non Apple hardware.

@TAFKAT: Could you do the OS X tests with a Firewire device being attached (be it audio or HD). Apple should supposedly have fixed the FW<->CPU dependencies, but it would be interesting to see the current impact.

Another trick would be to run Coolbook and use it's CPU Load slider at 9 or 10 (runs at low priority but keeps the CPU busy) to see the impact.

Timur,

Why would you turn Aero off, doesn't that disable open GL which is needed for certain plugin GUI's etc? Also doesn't Aero run from the GFX card anyway so no performance hit to the cpu like in XP.

And the realtime priority? what have you found this to improve?

Reason i ask is I don't do any of this and have amazing performance of my i7 Reaper x64 DAW.


MC

Hey Timur,

I actually run all my testing Win7 testing in Basic Mode, and have found in the past that I would get a measurable scaling improvement at ultra low latencies, not huge, but measurable. I know that goes against what Aero is supposed to be bringing to the table by offloading the GUI off the CPU, but I haven't seen any advantage in practice having it on. I'll give it a quick run up with Aero On at the lowest latency when I get some clean air, but I don't have the time to rerun all of the testing again.

BTW: In Cubendo, even if you have Aero enabled, all of the GUI elements within the application are running in Basic, so I didn't see the point in Aero past the eye candy. I am one that is yet to be convinced that Aero is living up to its theoretical advantages, and re the eye candy, I use custom Visual styles anyway which look identical in either mode..( see above screenshot ) :-)

Re forcing the apps to realtime priority, well if you have a close look at the results for all the tested DAW's on Win7 , they are all very close in performance, and all perform admirably. The only time I feel any type of priority anomalies is when the system is pretty much at break point , i.e above 95+% ASIO/CPU and realistically that is not a point that anyone would be working at , its purely for the empirical data.

What exactly were you hoping to see in the results by doing this ?

FWIW: There has been a Firewire Audio device attached to the system throughout the current testing , an M-Audio Profire 610 that has been used for the Protools based testing that I haven't posted the reports on yet, also you need to remember that I do not need to run any of the common tricks on OSX , as my system is an OSx86 system , so all the thermal and clocking controls are accessible at BIOS level. My experience with the performance of this system compared to official hardware is very similar to vEddY's. I reported that in detail in my other thread on Multiprocessor/Hyperthreading performance.

@TNM,

I haven't forgotten testing those other plugs, I have just been slammed the last week, not to mention putting PT9 thru its paces. Hopefully that thread I posted earlier passes moderation approval and gets posted in the PT goes Native sub forum, if not , I'll post the whole report here... :-)

@ Norbury,

Disabling Aero does not disable Open GL , I have not had any issues with plugin GUI's, nor have any of my clients reported any such issues.

The reason is simply that most audio applications are still using *non*-realtime priority 15 for their audio and midi threads instead of using *realtime* priorities 16-31. Aero/DWM (and Task-Manager btw) is using exactly the same priority 15 for its own threads that cannot be changed via TM even if it looks like that.

MMCSS is a working compromise offered by Windows, but unfortunately not used by our "professional" DAW developers (Sonar is one exception). The reason why a "compromise" is needed is simple: One you hand over full realtime control to a DAW application it can completely stall your system when it's overload (like too many effects running) or freezes/hangs itself. MMSCC leaves 20% (can be changed down to 10%) CPU load to be used by other processes - including Windows' own processes - should they need them. Samplitude offers to use a fixed realtime priority 31 via options btw (but likely without a "Watchdog" thread to keep the system from being overload).

I had a *very* convincing case of Aero's advantages:

The first 10 subversions of Live 7 could not be run on Vista in basic mode without drop-outs and high CPU load with even only a single audio-clip playing back. Turning on Aero solved the CPU load instantly, but with the drawback of priority conflicts (15!), so I had to turn Live to full realtime.

Another advantage of Aero is that *all* drawing is composed off-screen and then output together. Instead of having several applications all access the graphic-driver or respective Windows sub-systems it's all collected through DWM's layer (transparently for the application). This process alone helps with possible small bugs in GUI implementations, because DWM effectively "filters" everything and then communicates with the graphic-driver on its own. This can help with GUIs (especially VST ones) that are not coded efficiently.

Last but not least: Without Aero *every* single application produces CPU load to draw its own 2D GUI. With Aero they *all* offload their drawing to DWM. And like in the case with my Live 7 experience the CPU load of DWM can (not must) be lower than what the application would do on its own.

This would also even out the testing compared to OS X somewhat, because you could argue than on OS X "Aero" aka Quartz Compositor aka "WindowServer" is always running.

Seeing how these applications scale when given full realtime priority. You already wrote that are not using Aero and can push them to over 95% CPU load anyway, so there might not be much of a difference. When running Reaper at 48 samples via the Fireface UC I could push it closer toward 100% CPU load (aka more tracks) without dropouts compared to its default priority 15 setting.

While Live on Windows and OS X perform about the same, changing priority on Windows made a difference from ~80% max CPU load before audio drop-outs to close to 100% CPU load before drop-outs at 512 samples. At 64 samples it was like 50% vs. 65%. This effectively means that you can have more tracks and have more overall CPU headroom. This is likely due to some internal issues of Live where its own GUI competes with its audio/midi engine (does Cubase still offer an option for this?)!

When I checked Live's priority on OS X I found out that its process was already running at priority 99 (as far as I remember), so there was no room to push it further.

Not to mention that *no* DAW or plugin GUI makes use of Open GL. If they did they would have quite some tools for better GUI implementation at their disposal (i.e. hardware accelerated size-scaling). What Aero/DWM does is catch all 2D drawing calls that the single process GUIs put out, compose them into one single hardware accelerated 3D picture and then have the graphic-driver output the composition.

This is the reason why those neat little preview windows you get when moving the mouse-cursor over the task-bar application wont make too much of a CPU load difference even if they are running videos/animations inside. To your GPU it's all one single image.

Hey Timur,

That makes sense , but again it only goes further to support my findings that Aero is of no advantage for the majority of DAW application.

I do understand the theoretical advantages, just not convinced on the actual delivery.. :-)

Steinberg are also claiming to have MMCSS optimisation as early as C4.x , and SONAR does not feel in any way better/worse to me under heavy load in regards to the GUI. I do need to revisit SONAR with Aero at some point, but to be honest, I have pretty much closed the book on SONAR for reasons I mentioned in the other thread.

FWIW: I just quickly ran up all of the recent sessions for the Channel Strip Pro session on Win7 across Nuendo/Reaper and StudiOne @ 032 samples, there was no difference . So the positive is that Aero is not detrimental, but it isn't of any advantage on those apps either. Granted there really wasn't anywhere to move.

See below screen shot.


Nuendo 5 / RME HDSPe AIO @032 / 123 Channel Strip Pro / Aero ON

Its a bit harder to decipher with the custom visual style, but the GUI elements within Nuendo are running in Basic which can be seen with the upper right nav buttons not being on the top of the upper border like on the Windows elements, but on the bottom - as that is only visual change on that style when shifting from Aero to Basic.

I do remember you mentioning that a while back, and that is very specific to Live from my understanding. Is that still currently the situation with the latest builds ?

Also, just to be sure we are on the same page , I clearly stated that "I" hadn't experienced any improvement with any of the cross platform DAW applications I have been focusing on , Live not being one of the DAW's in the current testing pool due to the difficulty in navigating the methodology across to the session environment. We did discuss this a while back via PM, maybe we should revisit it and find a way to do it as I have had a few requests for Live benches.


In regards to evening out the testing more, not really Mate, you could easily argue that in Windows you have the choice of what works better for the specific DAW in operation, especially if Aero is proving to be detrimental to the results for a respective DAW.


With the respective Load Metering in the different DAW apps not being consistent in what they are actually representing, its hard to give a figure of max load. When I say 95+%, thats just a general observation , so for example in Cubendo its ASIO which may or may not be representative of TM in regards to readings , in Reaper its actual CPU/TM readings and I can get to a 100% reading in Reaper without drop outs as well at the lowest latencies without adjusting the priorities. I have a new Babyface here to test this week, so I'll see how that goes.

Well that is a significant improvement, but again the question arises whether that is specific to Live, and why ? Also if that is the case , why wouldn't the Live devs simply default to the higher priority ?

Re Cubase priority options, yes the options are still there, but its listed as being specific to Audio/MIDI, although setting it to Boost over Normal ( default) which gives priority of Audio over MIDI instead of equal balance, does smooth out ITB Video playback, so it does change something in regards to GUI priorities as well.