[Solved] Exceptions in processor when changing audio device settings

Solved here


Hello,

I am merging this reverb code into this compressor.

The code bases define parameters differently as well as process audio differently. The reverb has a CustomParameter class and uses loops for operations, while the compressor uses regular JUCE parameters and FloatVectorOperations calls. I refactored the reverb away from the custom parameters (previous thread), but it still uses loops for processing - I do plan to change this.


At any rate, I am getting exceptions when I modify settings in the AudioDeviceSelectorComponent pop-up during run time.

  1. Disabling “Active output channels” triggers “failed to find a compatible output configuration” on line 355 of juce_AudioProcessor.cpp. Clearly I need to either update the plugin to allow zero-output bus layouts. I have been reading the audio bus layouts tutorial but there are some methods that aren’t covered, including setPlayConfigDetails and setRateAndBufferSizeDetails, setBusesLayout, and several more.
    Can someone please share a tutorial, thread, or other resource that goes into detail about the other bus-related methods not covered in the official tutorial?

  2. Changing the input microphone to <none> leads to index-related errors in the reverb code. It seems that the sample size falls back to 48k instead of 44.1k, some indices are recalculated without the buffers being resized. To fix this, we should resize buffers in prepareToPlay, right, not in a process method?
    Any resources on this question would help as well. My plan is just to refactor away from that reverb to the built-in reverb and use FloatVectorOperations instead of loops. I hope that will alleviate some of the problems.

Thanks!

So a couple notes:

  • Reading about the BusesLayout struct and AudioChannelSet.
  • In the constructor of my compressor AudioProcessor, I tried to change the nested preprocessor statements which specify AudioChannelSets for inputBuses and outputBuses to the base constructor. I made
    .withInput("Input", AudioChannelSet::stereo(), true) and
    .withOutput("Output", AudioChannelSet::stereo(), true) be used
    regardless of JucePlugin_IsMidiEffect or JucePlugin_IsSynth.
    This did not make a difference.
    Next bullet point also nullifies this.
  • I set JucePlugin_PreferredChannelConfigurations via ProJucer to first {2,2},{1,2}, and then, {2,2},{1,2}{0, 2} [ per this thread ]. Neither got it worked, although defining the PreferredChannelConfigurations bypassed the above code via preprocessor.
  • Added these fields to one of my AudioProcessors (just one):
public:
        //==============================================================================
        // Bus Layouts -KGK
        //==============================================================================
        // Inputs -KGK
        Layouts.inputBuses.add(AudioChannelSet::mono());
        Layouts.inputBuses.add(AudioChannelSet::stereo());
        Layouts.inputBuses.add(AudioChannelSet::quadraphonic());
        // -Outputs -KGK
        Layouts.outputBuses.add(AudioChannelSet::mono());
        Layouts.outputBuses.add(AudioChannelSet::stereo()); 
        Layouts.outputBuses.add(AudioChannelSet::quadraphonic());

    private:
        BusesLayout Layouts; // Declare the BusesLayouts member
  • Tried to change isBusesLayoutSupported to go off my above Layouts member instead of hardcoded values, but realized the enum isn’t bitwise so I didn’t fully implement it
  • As before, setting PreferredChannelConfigurations in Projucer bypassed that anyways

Still not able to disable the active input channels (specifically “Output channel 1 + 2”) without the program crashing. Any tips?


After all this I am getting a weeeiird bug in some library code (juce_StandaloneFilterApp.cpp) that #ifdefs on JucePlugin_PreferredChannelConfigurations. Here’s the code, and the many errors:

not to mention another issue:

why is &Layouts not a valid parameter for the AudioProcessor (const BusesProperties& ioLayouts); constructor?

Two new developments:

  1. Building “Release” for PC eliminates the crash when you disable audio inputs during stream.
  2. Building for Mac (10.13.6) has the same types of issues, although a couple cases are not present (e.g. can disable audio input channels when audio input is muted, unlike PC, but not during a stream, same as PC).

Here is a crash report from Mac (extremely long!)

It’s very curious to us that the PC Release works without errors. Some optimization, or cut debug feature, on PC may be circumventing the problem?


I think I’ve solved this with the following steps –

  1. Putting watches on variables in my void Compressor::prepare(const juce::dsp::ProcessSpec& ps) and void Compressor::process(AudioBuffer<float>& buffer) methods.
  2. Comparing the number of channels, samples, etc. in the given ps to the given buffer.
  3. Upon finding some irregularities, refactoring my SidechainSignal away from a vector<float> to an AudioBuffer<float> and making sure it is configured in prepare to exactly match the provided ps.

There was a lot of back and forth as well as difficulty with Mac (copying .jucer file from windows into mac does not work!) so I’m leaving some details out, but, maybe it helps someone.

Curious … what are the issues here? I do this frequently and haven’t run into problems with this. Path-related?

I am honestly not sure.

Some backstory is needed: I have been developing on PC for my client, but he needed an updated Mac build. As he has the Mac and he does not prefer to use Git, I would send him changes from the PC for him to build on Mac.

This may have led to some configuration changes to the jucer file or Mac app signing/certificate permissions that were not well-tracked.

The complete, updated solution folder I emailed from PC - with Mac configuration changes made in the jucer - just couldn’t pass the Mac App signing process. Don’t know why.

In the end we just re-implemented the changes in XCode directly.


edit: We took another stab at using the same repo on windows and mac, and it’s working now. Just messed up the configuration the first time, and/or wasn’t familiar enough with Mac signing.

Gotcha, so its methodology then and not local to JUCE. Always frustrating when folks refuse to use git. It solves so many problems …

1 Like