[3.2] AAX terribly slow

Audio Plugins
#1

Hi guys,
I’m facing a weird issue… I have a plugin that uses about 7% CPU in release (test machine, Mac Mini 2011 i5) on both VST and AU, but where it comes to AAX the CPU gets to over 40%. I tried debugging, but on PT it’s hell on earth. Anyone experienced the same and can give me an advice?

Thanks!

#2

What’s your problem debugging… just attach Pro Tools (dev) to Xcode after it’s started.

Rail

#3

I don’t get any message in XCode console. I included AAX_Assert.h and used AAX_TRACE, but debugging using it’s own log file is cumbersome.

#4

Launch your ProTools instance from a Terminal window and all the DBGs will be printed there.

(That ProTools instance can also be attached to the Xcode debugger for breakpoints, etc.)

1 Like
#5

I think a profiler would be the better option, to find the performance problem. (I guess this might be a denormal problem State of the Art Denormal Prevention)

1 Like
#6

Thanks guys. I already profiled the code and it shows the same bottlenecks I have on all the other formats… but still, on PT the CPU gets very high and are not spikes. When I show the Performance Meters, one of the CPUs shows a value closer to the one I have with VST/AU (just a bit more), but the general meter goes over 40% without even starting playback.

@chkn I tried with ScopedNoDenormals, but the result is the same. So, it shouldn’t be a denormal problem in this case.

#7

Check that you are not allocating any memory in your process.
Protools do not like that at all.

#8

I’m using a bunch of AudioBuffer and maybe some HeapBlock

#9

if you are allocating those at each process and not keeping those as member variable then you should fix this.

#10

They are member variables. Maybe it’s just a glitch with PT 12.7. I’ll try to get an older version and see if there’s any difference.

#11

Confirmed… 7% on PT HD 12.3 and 100% on PT HD 12.7

1 Like
#12

Bumping this.

One user has reported much higher CPU consumption in Pro Tools 10.3.10 vs. using the same plugin in any other format/host on their machine.

Are there instructions other than mallocs that we should watch out for? Also, we’re still on the last JUCE 4 release. Have there been any important fixes in the JUCE 5 AAX wrapper (if this is a wrapper bug)?

#13

I found out that the culprit, in my case, was the way AAX manages the call to host. I used (bad practice, I know…) to get the BPM information at sample level. moved to block level and now works fine.