Standalone plugin (macOS) - super buggy audio?

Hi all, I’ve been having a frustration with JUCE more or less since I started developing with it, though I’ve been able to work around it, though to much annoyance and impact to my velocity.

I’m developing on macOS and I frequently test my plug-in via the Standalone Plugin target/mode, since it can connect to the Xcode debugger, breakpoint, etc. However, I’ve found several pretty major annoyances with the standalone mode:

  1. Probably half the time or more, the audio output is just totally borked. It’s super glitchy and garbled. I’m certain this is not an issue with my actually plug-ins, as I’ve never encountered this issue when building the actual VST3/AU/iOS target (which was incredibly fun and difficult to figure out…). It seems totally unpredictable and intermittent, and usually I just keep restarting it until it decides to behave.

  2. The standalone plugin likes to choose a random audio interface probably 10% of the time. I am basically always using Blackhole as my audio input and my main audio interface as my audio output. But sometimes, it likes to choose a random source for audio input (like my webcam, my USB hub…) and somehow this manages to bork my computer’s connection to my main audio interface and requires me to restart it (sometimes it seems to change the sample rate and cause the interface to start playing everything at chipmunk speeds, or the interface just gets totally messed up and outputs glitchy, stutter-y audio).

Has anyone else encountered anything like this? I’m building and running the standalone plug-in in debug mode so that I can get DBG statements, but I can’t imagine that it’s so inefficient that it’s smashing the CPU and unable to produce any audio at all really (at least with regards to #1). Is there a trick to this? Maybe allocating more memory/CPU to the standalone plug-in just so it can remain stable? Or maybe my computer just isn’t up to snuff? (16gb RAM M1 2020 Mac Mini - doesn’t have any problems at all running Ableton/Bitwig)

The standalone plugin has a settings file stored in Users/username/Library/Application Support/MyPlugin.settings

You can always delete that file in case weird settings gets stored.

Also notice that IIRC it will store the latest setting there on close (X button) - but not if you closed the plugin from the ‘stop’ button of the debugger.

So, you might want to make sure you actually save the settings you want in terms of interface and do a manual close.

1 Like

Not exactly the same as what you’re seeing, but on my M1 machine starting pretty much any audio app under a debugger while there’s already audio playing will cause the playing audio to glitch.

Are you talking about running the plugins in a host under a debugger? If not, I’d suggest giving that a go in a host like REAPER. If you get glitchy audio when running your plugin in REAPER under a debugger, then the glitching is likely due to debugging overhead rather than a problem in JUCE’s audio device handling.

You could also try running some of the JUCE example plugins (AudioPluginDemo etc.) in standalone mode under a debugger and see whether they exhibit the same problems. If they do, and non-JUCE audio apps do not, then that would be a strong indicator of a problem in JUCE.

There have been a few changes in this area on the upcoming JUCE 8 branch. I’d recommend checking that out and seeing whether it improves things for you.

The only time I get glitching in Standalone in Debug is if there are conditional breakpoints… or if the sample rate is high and I’m on the latest version of Sonoma on my MacBook M3 - see HALC_ProxyIOContext::IOWorkLoop: skipping cycle due to overload

Rail