AudioUnitBackend: Initialize parameters concurrently and load music effects too

[fwcd]

Based on #13890

This addresses a todo note in the AudioUnitBackend implementation:

mixxx/src/effects/backends/audiounit/audiounitbackend.mm

Lines 81 to 82 in 028e3ff

	// TODO: Should we perform this asynchronously (e.g. using Qt's
	// threading or GCD)?

With this PR, Audio Units plugins are now instantiated concurrently and out-of-process during the initial load. This has a few advantages over the current approach of instantiating everything synchronously:

• It's faster. Since all effect manifests are to be loaded synchronously while Mixxx is starting up, doing this concurrently for all plugins potentially improves startup time.
• It's more robust. Currently a bad plugin implementation could crash Mixxx during startup. By doing this out-of-process and adding a timeout, an unstable plugin shouldn't prevent Mixxx from starting up properly.

Additionally, we now load plugins of the category kAudioUnitType_MusicEffect (in addition to kAudioUnitType_Effect), which are MIDI controllable, but otherwise function just like regular effects. This is useful, since it lets Mixxx discover plugins like ShaperBox, which are marked as music effects.

[Swiftb0y]

I'm unsure who can properly review this. @m0dB has some apple-specific experience, right?

[m0dB]

Yes, I am very familiar with AU and I will review this when I find the time.

[fwcd]

I've rebased this to 2.5 since I believe the improvements in stability would be worth having there too. The GUI stuff (#13888) can then go to 2.6.

[Swiftb0y]

Not sure if its worth the regression risk. I'll leave that decision to @m0dB

[fwcd]

I ran into occasional crashes with ShaperBox at startup, the only reason why it didn't affect the release build was that "luckily" that plugin was marked as a music effect (and therefore not loaded). Since it could affect other (regular effect) plugins though, I think instantiating everything out-of-process would be worth it 😅

[m0dB]

Apart from my objection against the use of a sleep in a while loop instead of a wait condition, this LGTM.

[fwcd]

The test failures confuse me. Did I miss some race condition somewhere? I'm not familiar enough with QWaitCondition to say whether this usage is sound, would appreciate if someone could review that.

Screenshot

[fwcd]

I don't quite understand why we get sporadic segfaults with the QWaitCondition-based implementation. Unless I misunderstand how the wait condition is supposed to be used, the only explanation I see is that the wait condition doesn't like being invoked from some possibly GCD-managed background thread where our callback may be invoked, but that would kind of defeat the purpose of the wait condition and its associated mutex in the first place.

Any ideas? The sleep loop seemed to work more reliably, maybe it would be less risky to stick to that for now?

[m0dB]

Hm, let me quickly run this in the debugger if I can see what goes wrong. But yeah, let's stick with the while sleep loop otherwise.

[m0dB]

Please feel free to revert the QWaitCondition to the while sleep loop; I have a local branch with the version that crashes so I can debug this.

[m0dB]

Hm, mixxx-test freezes on me at:

[ RUN      ] AutoDJProcessorTest.FullIntroOutro_LongerIntro

GMOCK WARNING:
Uninteresting mock function call - returning directly.
    Function call: emitAutoDJStateChanged(0)
NOTE: You can safely ignore the above warning unless this call should not happen.  Do not suppress it by blindly adding an EXPECT_CALL() if you don't mean to enforce the call.  See https://github.com/google/googletest/blob/main/docs/gmock_cook_book.md#knowing-when-to-expect-useoncall for details.

GMOCK WARNING:
Uninteresting mock function call - returning directly.
    Function call: emitAutoDJStateChanged(1)
NOTE: You can safely ignore the above warning unless this call should not happen.  Do not suppress it by blindly adding an EXPECT_CALL() if you don't mean to enforce the call.  See https://github.com/google/googletest/blob/main/docs/gmock_cook_book.md#knowing-when-to-expect-useoncall for details.

Have to force quit.

[m0dB]

Same happens with your branch... If I skip the hanging test, it hangs on

[ RUN      ] ControllerScriptEngineLegacyTest.trigger
 test:warning [Main] "Script tried to connect to ([Test], co) using `connectControl` which is deprecated. Use `makeConnection` instead!"

I am going to try with 2.5, maybe something is messed up with my build environment.

Edit: ok, 2.5 also hangs. Going to do a clean build and see if that helps. Sorry for the noise.

[Swiftb0y]

the only explanation I see is that the wait condition doesn't like being invoked from some possibly GCD-managed background thread where our callback may be invoked,

Slightly related. I once hit a very nasty bug when calling pthread_cond_signal from a unix signal handler. Someone else fortunately figured out that that is apparently undefined behavior (though only resulted in a deadlock in 1/1000 cases). We fixed it by spinning on an atomic shared variable instead (which I'm not recommending here). I don't kow how the GCD stuff is implemented, but something similar may be the case here.

[Swiftb0y]

this looks reasonably correct to me according to the apple docs. A QWaitCondition would also just essentially wait, right?

[fwcd]

Yeah, I think so. Implementing the other wait with a GCD group instead of a QWaitCondition might btw be worth a try. Since the async handler is likely already invoked on some GCD queue, we'll probably run into less unexpected things there.

[Swiftb0y]

oops, my bad. I thought this was the place where the earlier comments where referring to, not the QThread::sleep in AudioUnitManifest.

[fwcd]

I suppose there must be a logic error somewhere. The dispatch group-based implementation seems to have the same issue as the QWaitCondition-based implementation.

I have reset the branch back to the sleep loop implementation (for some reason GitHub is still processing the push, not sure why the updated commits don't show up).