Show / Hide HAL Virtual Audio Device Based on App State

I am developing a macOS virtual audio device using an Audio Server Plug-In (HAL). I want the virtual device to be visible to all applications only when my main app is running, and completely hidden from all apps when the app is closed. The goal is to dynamically control device visibility based on app state without reinstalling the driver. What is the recommended way for the app to notify the HAL plug-in about its running or closed state? Any guidance on best-practice architecture for this scenario would be appreciated.

So, full disclaimer, I don't have a lot of direct experience with AudioServer plugins, so the advice I'm giving is coming from a general device management/architecture perspective, NOT from detailed experience with this particular plugin type.

In any case, the place I would probably start with here is the sample project "Building an Audio Server Plug-in and Driver Extension". You don't need any kind of DEXT for this, but that sample does how to deal with device appearance/disappearance, which is what your virtual device will be replicating. That is, your plugin will "present" a new device to the system when your app tells it to and destroy that plugin when your app goes away.

As a side note, I would not bother trying to get the DEXT component of that sample working, as the project is well out of date and, in my experience, getting any KEXT/DEXT working is inevitably a time-consuming, tedious, and annoying process [1]. Please feel free to skip that pain.

That then leads to here:

What is the recommended way for the app to notify the HAL plug-in about its running or closed state?

Typically, this is done through XPC, using the mechanism described in QA1811 [2]. So your app/helper component would use that XPC connection as its "back channel" to control the ASP, including triggerings like device appearance/disappearance.

[1] I've been building KEXTs (and now DEXTs) for macOS since ~2001. Across that entire time span, it's ALWAYS taken me 1-2 days to get one loading correctly. I've never encountered the same problem or made the same mistake twice... but I've also never gotten any faster. There are a lot of details that have to be perfect and limited visibility into what's going on, which inevitably leads to a lot of fiddling until it suddenly works.

[2] The QA uses the term "mach services", but mach is actually the transport layer XPC is implemented on top.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware