Audio engine occasionally fails in standalone

Audio Plugins
1

Hey folks, kind of tearing my hair out with an issue and figured I’d just ask to see if anyone has experienced an error like this.

Basically, occasionally when I run my plug-in in standalone debug via Xcode, the audio engine seems to seize up and glitch out, or go fully silent. It’s usually true right off the bat when I open the app. The execution seems to continue fine. The UI is responsive and represents what’s going on. I can use a breakpoint to show that processBlock is still chugging along fine. I don’t have any errors in the console saying that a cycle got skipped due to overload either.

The strange part is that if I pause the execution (e.g., with a breakpoint) and then resume the app, it almost always wakes up and works fine. I can even add a breakpoint to an arbitrary place in code that doesn’t fire.

I’ve checked every possible place I can think to verify that NaNs, infs, or any value > abs(1.0f) isn’t poisoning a buffer or DSP unit. I’ve commented out the entire UI to ensure it’s not accessing or corrupting anything. Double checked that multiple processBlocks aren’t running concurrently, nor is prepareToPlay getting called somewhere. There’s pretty much nothing blocking in processBlock (i.e.., mutexes). If I pause execution, it’s not stuck in some infinite loop or waiting on a mutex either.

I’ve also added some atomic variables that count how many times processBlock has been called and keep track of the RMS of the buffer that gets passed as a parameter to processBlock. I then paint those variables in the UI. Even when the audio is seizing up or completely silent, I can clearly see that processBlock is continuing to get called, and I can see the RMS change as expected with audio input and output (even when not actually hearing it). I set those at the very end of the method too, since nothing in the entire method has poisoned the buffer or anything like that.

I’ve only ever had this issue with this product, so I don’t think it’s an Xcode thing or my machine or anything. I also can’t recall ever experiencing this issue in release mode and/or in a DAW, but the frequency of the issue really worries me.

Anyway, I know that doesn’t contain much specific information, but I truly have no idea what the issue could be, so short of pasting my entire codebase into here I’m not sure if anything specifically would be that helpful. Just wondering if this rings a bell for anyone.

2

I use standalone and have never come across this.

3

I dont take audio stability serious unless I compile for release. My work on mac/ios never works well in debug mode, it just shows the errors, but doesn’t perform well audio wise.

4

Yeah I hear that. I’m at the point where I’ll probably just declare bankruptcy on the issue since I’ve thrown every possible test I can think of at it.

At this point I think I’ll just look out for whether it occurs in release mode/DAWs. I think my main concern is just that debug is surfacing an unlikely error (by making it much more likely) that I need to fix. And that it makes testing really annoying when the audio engine is FUBAR around 10% of the time

5

Could it be that your audio thread is completely overloaded? I’ve noticed exactly the the same behaviour with a very cpu-demanding app (at least on the audio side). Audio callbacks, UI still responsive, but no audio output. I’ve found that AudioDeviceManager::getXRunCount() increases all the time, so it seems it just can’t make the deadline for the requested buffer, and the next, …

6

It’s certainly possible, though I’ve still experienced the issue after commenting out almost everything in processBlock…

I added a watchdog timer just to compare the wallclock time at the start and end of processBlock to see if it’s executing within the right amount of time (less than buffer.getSampleNum()/ sampleRate seconds). I do occasionally see it get exceeded once or twice after init but it doesn’t seem correlated with the issue. FWIW I also don’t see a bunch of HALC_ProxyIOContext::IOWorkLoop: skipping cycle due to overload though not sure how reliable that is.

I’ll take a look at getXRunCount, maybe that’ll yield something.