BUG: dsp::Convolution crashes in AAX on macOS Monterey on M1


I’m getting a crash in ProTools 2021 on the latest macOS Monterey build running on a M1 macbook. I have narrowed it down and it seems to be caused by the dsp::Convolution process call. It does not happen with VST3 or AU formats on the same macbook, or with AAX running on Big Sur (also on a M1 machine). So it seems specific to the convolution module in an AAX plugin on Monterey.

I’m loading the impulse as binary data.
AAX SDK 2.3.2
JUCE 6.1.2

I have reproduced the crash in a simple plugin like this:

juce::dsp::Convolution convolution;

prepareToPlay (double sampleRate, int samplesPerBlock) 
    dsp::ProcessSpec spec;
    spec.sampleRate = sampleRate;
    convolution.prepare (spec);
    convolution.loadImpulseResponse(BinaryData::somefile_wav, BinaryData::somefile_wavSize, dsp::Convolution::Stereo::yes, dsp::Convolution::Trim::no, 0, dsp::Convolution::Normalise::no);

process (dsp::ProcessContextReplacing<float> context)

Can you go any deeper into the call stack to see what exactly is crashing? Download the Pro Tools Developer version and attach a debugger to learn more as on an M1 you’re not going to get the usual crash details coming through (I think there’s an issue with crash reporter coming into play). I’ve observed some strange crashes in Monterey running Pro Tools on M1 when calling Accelerate’s IFFT routine, so it could be related to that. Totally different algorithm, but suspiciously similar symptoms and I suspect the juce convolution will be using an Accelerate IFFT at some stage. Also will be useful to know if it happens on an Intel machine when you are not using Intel IPP for acceleration so it leans into the Accelerate framework there too.

The main problem is that AFAIK, Pro Tools and AAX are not Silicon native yet. Furthermore, debugging AAX requires the use of external tools, since (as far as I remember) you cannot attach a debugger to PT process.

How accurate is the example code you posted? I wouldn’t be surprised if this crashes, given that you’re not initialising the ProcessSpec’s block size and channel count data members. Are you setting these data members in your actual test plugin?

Can you go any deeper into the call stack to see what exactly is crashing?

@hill-matthew This is a test machine with no development tools installed yet, but I’ll try that. On my Big Sur M1 machine I haven’t been able to attach a debugger to anything though.

The main problem is that AFAIK, Pro Tools and AAX are not Silicon native yet.

@lcapozzi Right, but ProTools and plugins runs fine via Rosetta. The test AAX plugin here works fine on another M1 mac running Big Sur, and also runs fine on Monterey if I don’t call convolution.process().

How accurate is the example code you posted? I wouldn’t be surprised if this crashes, given that you’re not initialising the ProcessSpec’s block size and channel count data members. Are you setting these data members in your actual test plugin?

@reuk Sorry about that. I am indeed setting both maximumBlockSize and numChannels. As mentioned, the same plugin doesn’t crash as VST3 and AU, and even as AAX on Big Sur with the same chip.

Has anyone tried reproducing? Wonder if I’m the only one getting this crash?

Yes I tried reproducing this using the Juce convolver, but also my own convolver, it crashes in the same place. That’s too much of a coincidence as they share no code whatsoever so are doing totally different things until they both dip into the vDSP IFFT.

M1 Big Sur: no crash
M1 Monterey: crash in vDSP_fft_zrop
Intel Big Sur: no crash
Intel Monterey: crash in vDSP_fft_zrop

0 CFnd 0x10deea797 SIGABRTHandler(int) + 56
1 libsystem_kernel.dylib 0x7ff806af62a2 __pthread_sigmask + 10
2 libsystem_platform.dylib 0x7ff806b42e2d _sigtramp + 29
3 ??? 0x0 ???
4 libsystem_c.dylib 0x7ff806a79d10 abort + 123
5 CFnd 0x10df2b03d stack_chk_fail_substitute() + 9
6 libvDSP.dylib 0x7ff810e50e28 vDSP_fft_zrop + 168
7 libvDSP.dylib 0x7ff810f7cb9a vDSP_fft_zrip + 26
8 PLUGIN 0x14e058beb juce::dsp::AppleFFT::performRealOnlyInverseTransform(float*) const + 91
9 PLUGIN 0x14e063604 juce::dsp::ConvolutionEngine::processSamples(float const*, float*, unsigned long) + 2132
10 PLUGIN 0x14e062b1a juce::dsp::Convolution::Pimpl::processSamples(juce::dsp::AudioBlock const&, juce::dsp::AudioBlock&) + 1082
11 PLUGIN 0x14e06213d juce::dsp::Convolution::processSamples(juce::dsp::AudioBlock const&, juce::dsp::AudioBlock&, bool) + 509
12 PLUGIN 0x14df9070c Proj29Reveal_AudioProcessor::processBlock(juce::AudioBuffer&, juce::MidiBuffer&) + 460
13 PLUGIN 0x14df87fed AAXClasses::JuceAAX_Processor::process(float* const*, int, int, bool, AAX_IMIDINode*, AAX_IMIDINode*) + 557
14 PLUGIN 0x14df87baf AAXClasses::algorithmProcessCallback(AAXClasses::JUCEAlgorithmContext* const*, void const*) + 2159
15 AAXHost 0x135a607ca AAXH_CComponentNative::RenderAudio(int, float const**, int, float**, int, long long, long long) + 584
16 AAXHost 0x1359ba082 AAXH_CPlugIn::RenderAudio(float const* const*, int, float* const*, int, int, long long, long long) + 342
17 AAE 0x13651e2c8 CAAXEffectInstance::AAXWorkerCallback(void*, SPlugInRTGlobals*) + 600
18 AAE 0x1363b2aba CHostWorkerEngineImpl::ExecuteWorkerChain(CWorkerChain*, CProcessingThread*) + 1274
19 AAE 0x1363b68a6 CHostWorkerEngineImpl::ProcessWorkerChain(CWorkerChain*, CProcessingThread*) + 470
20 AAE 0x1364ca1eb avid::aae::CHostWorkerEngineProcessingThreadPool::ProcessLoop(CProcessingThread*) + 219
21 AAE 0x13647f84f CSimpleThread::StaticThreadProc(void*, IPSThread*) + 15
22 DigiPlatformSupport 0x10dad40ef CTask_Imp::MacOSXMasterThreadProc(void*) + 115
23 libsystem_pthread.dylib 0x7ff806b2d514 _pthread_start + 125
24 libsystem_pthread.dylib 0x7ff806b2902f thread_start + 15

Clearly there is a problem when trying to use the Accelerate vDSP IFFT routine in Pro Tools running on Monterey. No crashes in any other hosts. So, nothing to do with M1 emulation, I suspect Avid will need to look into this when they are updating for Monterey compatibility.

@reuk Will the JUCE team be reaching out to Avid regarding this issue? There’s probably a better chance of it getting attention if it’s coming from the JUCE team instead of some random me.

I was hoping to repro the issue myself before escalating but unfortunately we haven’t had access to an M1 machine running Monterey. I think the official Monterey release happened today, so hopefully we can update our M1 test machine shortly and test the issue ourselves.

Makes sense. I’ve only tried it on an M1 machine but according to the tests by @Verbonaut above it also crashes on Intel machines running Monterey.

It made no difference to me, Intel or Apple Silicon, same crash.

In this case I can offer you a workaround: Use Intel’s IPP FFT on x86_64 platform rather than Apple’s. From my tests it’s faster than vDSP anyhow.

I was offering a means of reproducing the fault for those without an M1 system, indeed IPP is faster than vDSP for shipping code and I don’t use it unless I have to.

Hi all - this is being investigated by Avid. Our bug tracker number for this is PT-278282, with a corresponding Apple feedback ID of FB9715681. So far we do not have any information regarding the cause of the crash, unfortunately, but it certainly relates to using FFT functions provided by the Accelerate framework.

Rob Majors
Pro Tools Software


We have identified the cause of this crash. We have not found any way to work around this crash when running the vDSP_fft_zrip function on Monterey in Pro Tools 2021.10 or earlier, but we will apply a fix in time for the first Pro Tools release that is officially qualified for macOS Monterey.


We have just encountered this bug on Monterey. Any update on when this is going to be fixed?

1 Like

Yes, good news. This will be fixed in the next update to Pro Tools regardless of whether or not that update officially supports Monterey.