AudioDriverKit Extension for Virtual Devices?

At 3:38-4:00 in the session video, it seems Baek San Chang says that AudioDriverKit will not be allowed to be used for virtual audio devices...

Keep in mind that the sample code presented is purely for demonstrative purpses and creates a virtual audio driver that is not associated with a hardware device, and so entitlements will not be granted for that kind of use case.

For virtual audio driver, where device is all that is needed, the audio server plugin driver model should continue to be used.

The mentioning of sample code is a little confusing; Does he mean the entitlements for hardware access won't be granted for a virtual device? That would seem obvious. But if he means the entitlements for driver kit extensions (com.apple.developer.driverkit and com.apple.developer.driverkit.allow-any-userclient-access) won't be granted for virtual audio devices, and this is why AudioServerPlugins should still be used, then that's another story.

Are we allowed to use AudioDriverKit Extension for Virtual Devices?

The benefit of having the extension bundled with the app rather than requiring an installer is a significant reason to use an extension if allowed.

Up vote post of swillits Down vote post of swillits
1.4k views
Posted by
swillits
Reply
Add a Comment

Replies

I very much understood this as “you will not get the necessary DriverKit entitlements for a virtual device” (and to keep using an Audio Server PlugIn for that purpose). So we’ll be stuck with installers and non-App Store distribution.

Posted by
maven
Post not yet marked as solved Up vote reply of maven Down vote reply of maven

  • I'm not sure if this is the right place to ask this question, but.....

    Both Promise and SoftRAID today have to provide their trusted kernel extension that get loaded into /Library/Extensions, and subsequently get loaded across a reboot. Both these vendors say the DriverKit they require is over a year late in being delivered. Can anyone at Apple say when this issue might get resolved as the current kexts from these two 3rd parties have to be loaded for the "Reduce Security" M1 Macs, and worse still, they CANNOT be loaded for a bootable external macOS Big Sur nor the new macOS Monterey. Thank you.

    —
    bxxs

  • I can be reached at barrysharp AT Mac DOT com

    —
    bxxs
Add a Comment

Hi,

I also got stuck when developing a virtual audio driver and I based it on AudioDriverKit and the sample https://developer.apple.com/documentation/audiodriverkit/creating_an_audio_device_driver . In the end it's running perfectly and the installation from inside my SwiftApp is fine but it seems that I unfortunately over read that you shouldn't use AudioDriverKit for virtual drivers as you will not get the required entitlements. Searching for entitlements etc. I also found this thread.

Now I started to have look at the sample https://developer.apple.com/documentation/coreaudio/building_an_audio_server_plug-in_and_driver_extension which is probably the way I should go. On the other hand this sample also seems to require the entitlements com.apple.developer.driverkit com.apple.developer.driverkit.transport.usb and for the client com.apple.developer.driverkit.userclient-access . Assuming I'd be given these entitlements for a virtual driver the only one I'm missing is com.apple.developer.driverkit.family.audio (while I think I wouldn't need com.apple.developer.driverkit.transport.usb) to be able to use AudioDriverKit. To me it also looks like AudioDriverKit is not something completely different to using the approach shown in SimpleAudio but really allows much more clean and modern C++ code.

Does Apple think about giving the com.apple.developer.driverkit.family.audio also for virtual drivers (and if yes, when?) or is there a serious reason why this will never happen?

Thanks and best regards, Johannes

Posted by
JFreyberger
Up vote reply of JFreyberger Down vote reply of JFreyberger
Add a Comment