AAX cpu overload dialog box on first playback only

I am using PT 12.5.0x71 developer app, mac 10.13, latest JUCE. I have been using and testing my plugin for a long time and I would get the occasional cpu overload dialog (error -6101), and yet I do not do anything cpu intensive. So, I wanted to reorganize my code and get to the bottom of these issues. After reorganizing, I get a cpu overload dialog on first playback through my plugin 100% of the time. Thereafter, I never get a cpu overload. Note, AAX starts streaming audio as soon as the plugin is inserted…no issues there…then I start playback and get the cpu overload dialog…then I start/stop playback as many times as I want after that and there is no issue.

I thought maybe I was allocating some memory in the real time code path, but can’t find anything. I timestamped the processBlock function and it never takes more than 1ms. Since AAX just presents a dialog for cpu overload, I have no stack trace or anything to help me identify what is triggering that dialog. I don’t even know if the problem is in processBlock. Any ideas?

1 Like

Did you ever get to the bottom of this? We’re seeing more of these dialogs in the latest version of Pro Tools even in plugins that have minimal CPU overhead.

That’s a bug I filed in our software, too! I assumed it was a mistake I made in updating my plugin, but haven’t investigate the issue yet. Same problem. Very first time I hit play, I get an overload. After that, no problems. Maybe we need to ask Avid how to tell what might trigger the dialog besides taking too long?

1 Like

If this happen on macOS you can run it under the Instruments profiler. Pro Tools will emit a profiler signpost as soon as the overload happens which appears in the profilers timeline. This gives you some very good debugging insight since you can inspect what’s happening right before in the profiler, e.g. hot codepaths or locks being held. We spotted the cause of a very similar AAX issue in our code base this way.

1 Like

Does anyone know if plugin allocation/creation itself needs to happen by the render deadline in Pro Tools?

If so, that seems like an unreasonable requirement, given that some plugins will inherently require large/time-consuming memory allocations.

Are you querying/getting your plug-in editor on audio callback?

There was a change a while ago making this use the audio thread lock.

Not sure I follow what you mean, but we use FIFO’s for all communication between the editor / dsp during processBlock().

I see mine only happens after loading an old session. I’m probably forgetting to allocate something, and it allocates on first use, which causes the overload.

Profiling in Instruments, it looks like the signpost is emitted right after our AudioProcessor construction (but before the audio DSP has been created or prepareToPlay has been called).