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!
What’s your problem debugging… just attach Pro Tools (dev) to Xcode after it’s started.
Rail
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.
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.)
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)
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.
Check that you are not allocating any memory in your process.
Protools do not like that at all.
if you are allocating those at each process and not keeping those as member variable then you should fix this.
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.
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)?
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.