AAX Lower CPU Usage?

[justus1900]

I did a channel strip on my new song with 62 Tracks. I put 62 AVID Channel Strips AAX on the song and the CPU usage was like 42% I put 62 McDSP Channel G Compacts RTAS on the 62 Tracks and the CPU usage was 68%. I cant wait for McDSP and all of my Plug-Ins to be AAX.

[Emcha_audio]

I did a channel strip on my new song with 62 Tracks. I put 62 AVID Channel Strips AAX on the song and the CPU usage was like 42% I put 62 McDSP Channel G Compacts RTAS on the 62 Tracks and the CPU usage was 68%. I cant wait for McDSP and all of my Plug-Ins to be AAX.

Something to take into account, is that they are not the same plugin at all. If you have the same plugins in rtas and aax native, I would try that to see a real comparison between the two.

[chrisdee]

I think you have to compare the same version of the same plugin for both RTAS and AAX for it to be comparable at all.

[janmuths]

AAX Lower CPU Usage?

I don't agree. When the Softube AAX plug ins came out I did some extensive testing: AAX-native vs. RTAS.

Started with moving the RTAS plug-in to the unused folder. Created a session with 64 mono-tracks, put TLA-100 on all of them. Saved. Quit PT. Moved the AAX plug in to unused, and the RTAS version back to the plug-ins folder. Opened session again.

Same CPU reading in general. The CPU usage isn't a fix value, but fluctuates a little. Any differences were within the typical fluctuation margin.

I came to the conclusion that there is no noticeable CPU usage difference between Softube's AAX-native and RTAS plug ins.

This may be different with other plug ins. But for a true comparison one MUST compare the RTAS and AAX native version of the same plug in.

My 2 cents.

Cheers,

Jan

[tamasdragon]

The question is: is AAX inherently more efficient than RTAS?
It would be good to see some "lab" comparison between the two formats. My guess is that we will only see the real advantage (if any) when Pro Tools 11 will be here.

[JFreak]

The question is: is AAX inherently more efficient than RTAS?

No.

Plugins do calculations. Calculations eat CPU. If you come up with a magical way to calculate 1+1=2 faster, you're a magician (or a witch that should be burned).

RTAS or AAX or AU or VST or whatever are just "wrappers" for the algorithm that does the calculations. They eat very little CPU time. But obviously, if you instatiate a wrapper that takes a VST plug and introduces it as RTAS plug you're wrapping a wrapper that contains the actual calculations, which means it's not that efficient. But AAX is not that kind of a kludge, it's a real thing and makes it possible to design 64-bit plugins for PT.

To summarize: it is the algorithm (calculations) that eat CPU. Not the format.

[justus1900]

Something to take into account, is that they are not the same plugin at all. If you have the same plugins in rtas and aax native, I would try that to see a real comparison between the two.

I was thinking that the difference between two different Plug-In could be allot of this, but when you are doing a HUGE Mix the less CPU Hog a Plug-In is the better. After going from Pro Tools 8,9 and 10 like on the day each one was released I cant wait for Pro Tools 11 to come out see how it works on like a 100 or more Track session Mix.

[dankin]

Plugins do calculations. Calculations eat CPU. If you come up with a magical way to calculate 1+1=2 faster, you're a magician (or a witch that should be burned).

This is how I see it too. I don't really see how the AAX version of a given plugin is going to be suddenly more efficient than the RTAS version of the same plugin providing it's an audio plugin and not a VI plugin. I own Logic and Cubase as well as PT10 and the same waves/softube/mcdsp/whatever plugin in VST, AU and RTAS uses about the same CPU in all of them in my experience. On my system I can actually run a lot more RTAS plugins in PT than I can VST in Cubase of the same exact plugin. Obviously in Cubase you can "freeze" tracks which would allow you to have more things going but I'm only comparing real time. Logic makes you think the AU format is more efficient but that's just because Logic buffers all the unarmed tracks at 1024 no matter what your actual audio buffer is set at. So while you can maybe run more plugins in Logic it's not because of the AU format but because of how Logic works.
I'm not buying into the "wait til PT 11" idea either. Maybe there will be a slight change but most likely for the typical EQ/compressor/reverb plugin it will be about the same. The biggest change would be if they gave us the ability to freeze a track, which you can technically do now it's just not very convenient. Now where there hopefully will be a major difference is with Virtual Instruments. That's where PT absolutely fails at the moment. I can run hundreds of rtas eq's and compressors but one instance of Omnisphere can bring it to it's knees. This is what I'm hoping will change.

[Neil Pickles]

It's my understanding that when everything goes AAX and possibly in line with PT11 there will be better useage of multiplecores/threads/processors and that is all part of the push for AAX also the need for it and getting rid of RTAS.

So if that is the case although the PIs aren't necessarilly more efficient you may be able to get "more" from say a dual processor system than before so indirectly I guess you could argue it will be more efficient in the longer run.

That's my take on it anyway. Right now on 10.2 apart from much faster load up times of AAX etc I'm not seeing much difference in actual performance.

[Pinball Wizard]

I did an experiment a few months ago when the Bomb Factory 1176 was ported to AAX. Unfortunately I forgot the exact numbers, but here is the essence of what I did. This was with 10.2.0 on Windows 7, 64 bit.

I choked down my cpu usage to only 1 core.

I loaded up a number of BF1176 RTAS plug-ins into a session (I think it was 40).

I noted the CPU (Native) usage in the System Usage window.

I then installed the AAX version and repeated the experiment.

The result was that the AAX version used slightly more CPU than the RTAS version. I'm sorry, I didn't write down the results & I forgot the exact numbers but they were close.

There are, of course, some problems with this experiment. The first one is that it really should be done with multiple cores running as it is just possible that the AAX version may have better results with multiple cores. Also the BF1176 may or may not be representative of other plug-ins.

UMMV!

I can't repeat the experiment now as I am about to start a big project, but it isn't difficult & I invite others to repeat the experiment and report back with their measurements.

[meech]

I haven't noticed a difference between RTAS and AAX in terms of CPU usage, but I do see huge CPU differences between Pro Tools and other DAWs. For example, any plugin combination I pull up in Pro Tools consistently uses up TWICE the CPU compared to when I host the plugins in Vienna Ensemble Pro. I measure this with Activity Monitor, not the cpu meters within the applications.

[DaveTremblay]

Interesting thread. Maybe I can help shed some light on expectations.

AAX vs. RTAS:

Previous comments on the thread are correct. The algorithm code inside the actual plug-in under test is, by far, the dominant effect as far as clock cycles. There is some system code that does signal routing and such, but it is pretty lightweight. If I remember my profiling of this a little while back, we spend less than 1% of our time in system code while running a pretty loaded session. And that code doesn't really change much between RTAS and AAX considering we have to maintain support for both formats. I'll leave that topic right there.

That said, you could still expect to see some differences between AAX and RTAS. Sometimes because we, or other plug-in developers, might take the opportunity to increase precision. Or possibly because we're using the same code for the DSP, which encourages us to really hand tune every line of code. Often times, optimizations for the DSP will benefit the Native performance as well. Occasionally, there is a tradeoff between DSP and Native performance, but its pretty rare.

Another thing to mention on this topic is buffer size. Historically, RTAS had the option of running variable buffer size or a fixed 32 sample buffer size. The fixed 32 sample buffer size was not related to hardware buffer size at all, just part of the plug-in spec back in the day. In general, larger buffers are more efficient. Processing plug-ins at the largest possible buffer size (hardware buffer size in most cases) will yield optimal results. So again, you have to compare AAX to RTAS of the same exact plug-in, but you might see some gains for AAX in these cases.

Measuring Performance:

Now, to the major caveat. Measuring performance is tricky. Sometimes holding on to threads can yield quicker wakeup times, which equates to less likelihood of glitching the audio. This may also make certain performance tools report higher CPU usage that we're actually using.

Bottom line is that testing for glitches in the audio is king. Don't trust your CPU meters too much. Some audio software will be prone to glitching audio at 50% CPU, others won't start glitching until 80-90%. And ultimately, that is what matters. Oh, and DSP systems shouldn't ever glitch, no matter how hard you push them. (In case you were wondering, that's one of the primary reasons we still make them) :)

Dave

[Dnnspv]

AAX vs. RTAS should not be the focus. As meech pointed out, there is a big difference between PT native and VEPro (Cubase, Reaper, Logic) regarding VI usage on the same system, same plugins, same low buffer. If AAX, as mentioned earlier, is just a wrapper that does not factor much in terms of performance, then we should expect a lot of changes under the PT hood to solve the issue.

[DaveTremblay]

AAX vs. RTAS should not be the focus. As meech pointed out, there is a big difference between PT native and VEPro (Cubase, Reaper, Logic) regarding VI usage on the same system, same plugins, same low buffer. If AAX, as mentioned earlier, is just a wrapper that does not factor much in terms of performance, then we should expect a lot of changes under the PT hood to solve the issue.

It's not really just a wrapper. There are differences in the levels of flexibility with AAX plug-ins, but while we're still supporting RTAS and TDM, there are limits to what we can do.

Dave

[tamasdragon]

It's not really just a wrapper. There are differences in the levels of flexibility with AAX plug-ins, but while we're still supporting RTAS and TDM, there are limits to what we can do.

Dave

So it means that we can expect changes in the future (PT11) when TDM and RTAS support will be dropped?
I absolutely understand the limitations because of the compatibility.