juce_AAX_Wrapper sets incorrect block size when switching sidechain input

Audio Plugins
1

If you switch the “key Input” in Pro Tools, it is possible that an incorrect block size is reported to the AudioProcessor. In the worst case, this can lead to crashes.

I guess that in the juce_AAX_Wrapper method JuceAAX_Processor::updateSidechainState() the line

audioProcessor.prepareToPlay (audioProcessor.getSampleRate(), audioProcessor.getBlockSize());

should be replaced by

audioProcessor.prepareToPlay (audioProcessor.getSampleRate(), maxBufferSize);

To verify I did the following modifications to the NoiseGatePluginDemo.h from the JUCE examples:

  1. Add private member mMaximumSamplesPerBlock:
...
private:
    //==============================================================================
    AudioParameterFloat* threshold;
    AudioParameterFloat* alpha;
    int sampleCountDown;
    int mMaximumSamplesPerBlock { 0 };
    float lowPassCoeff;
...
  1. Set mMaximumSamplesPerBlock in prepareToPlay():
void prepareToPlay (double, int maximumSamplesPerBlock) override 
{ 
    lowPassCoeff = 0.0f;
    sampleCountDown = 0;
    mMaximumSamplesPerBlock = maximumSamplesPerBlock;
}
  1. Compare number of samples of the current buffer with mMaximumSamplesPerBlock in processBlock():
void processBlock (AudioBuffer<float>& buffer, MidiBuffer&) override
{
    const auto numSamples = buffer.getNumSamples();

    if (numSamples > mMaximumSamplesPerBlock)
    {
        jassertfalse;
    }
    ...

Now you can reproduce the problem with the steps below:

  1. Set a breakpoint in prepareToPlay().

  2. Open Pro Tools and set the “H/W Buffer Size” to 256 samples via Menu → Settings → Playback Engine → H/W Buffer Size.
    BufferSize

  3. Debug via “attach to process”.

  4. Pro Tools: Load the NoiseGatePlugin to a track.
    Explanation:

    • As expected JuceAAX_Processor::preparePlugin() calls prepareToPlay() with the default lastBufferSize of 1024 samples.

  5. Pro Tools: Set “key input” to “interface → … 1 (Mono)”
    1

    Explanation:

    • JuceAAX_Processor::updateSidechainState() calls prepareToPlay() with bufferSize of 1024 samples
    • JuceAAX_Processor::process() calls setRateAndBufferSizeDetails() with new bufferSize of 256 samples.

  6. Pro Tools: Set “key input” back to “no key input”.
    2

    Explanation:

    • JuceAAX_Processor::updateSidechainState() calls prepareToPlay() with bufferSize of 256 samples.
    • JuceAAX_Processor::process() calls setRateAndBufferSizeDetails() with new bufferSize of 1024 samples.
    • You end up in the assertion in processBlock(), because the number of samples of the delivered buffer is greater (1024) than the reported maximum number of samples (256). This can cause trouble if you use internal buffers and set their size in prepareToPlay().

I checked this with both JUCE 7.0.2 and the current develop branch (commit 128e980be4e7d499ba26e823ed20c02803bd0799) on Windows 10 with “ASIO4All v2” as playback engine. But you can use an audio interface of your choise.

With the line I listed at the beginning, the problem seems to be fixed and you don’t end up in the assertion.

Can you confirm the problem and the fix?

1 Like
2

@reuk Sorry to interrupt, but I would appreciate a response from the JUCE team to my question. Thank you very much in advance.

3

Sometimes things tend to take a while. see Auto-close threads after 12 months - #15 by yairadix

I suggest that until it may be fixed, either modify your plugin to not crash when the reported block-size mismatches the actual one, or fix it in your JUCE branch. Ideally also share the fix here so you can hopefully get feedback.

2 Likes
4

And the lack of a properly managed issue tracker frustrates an user once per month here!
Personally i bookmark my BR and bump it from time to time :laughing:

2 Likes
5

Thanks for reporting, I’ve got a fix on the way.

It might take a little while for the fix to reach develop. Some of the team are away at the moment, so reviews might take a bit longer than normal.

1 Like
6

Thanks again for reporting. The fix is now on the develop branch:

1 Like
7

@reuk
Thank you for fixing the issue. The fix works flawlessly.