Modern AudioServer replacement for USB Audio Core Audio HAL plugins?
Modern AudioServer replacement for USB Audio Core Audio HAL plugins?
- Subject: Modern AudioServer replacement for USB Audio Core Audio HAL plugins?
- From: Phil Dennis-Jordan <email@hidden>
- Date: Mon, 11 Feb 2019 11:23:03 +0100
Hi,
I'm trying to implement full macOS support for a USB audio device; the
device largely follows the USB Audio Class specification, but has a
bunch of features that are controlled via a nonstandard HID interface.
The AppleUSBAudioDevice kext driver handles the device just fine, but
of course not the weird HID features. I can control those from a
standalone app using IOHIDManager, but I'd ideally like to be able to
turn those features into Core Audio HAL controls (e.g. source selector
controls) without rewriting a driver from scratch for the USB Audio
Class aspects which after all are working fine.
From TN2274 and other (largely archived) Apple developer docs, I can
find the following ways to extend the AppleUSBAudio driver:
* AppleUSBAudioPlugin kexts as per "SampleUSBAudioPlugin". This seems
to intended primarily for performing extra processing stream samples.
I don't see a sensible way of adding additional audio controls.
* Creating a codeless AppleUSBMergeNub kext and overriding the
IOAudioEngineCoreAudioPlugIn property to point to a bundle with a HAL
plugin. (implementing CoreAudio/AudioDriverPlugIn.h) I *think* this
might have been the way to achieve what I'm trying to do on older
versions of macOS, pre library-validation - it looks like the plugin
bundle acted as a filter for HAL properties, so I could have
potentially overridden the list of audio controls for the device.
Nowadays, this doesn't seem a practical approach as my plugin wouldn't
be signed by Apple and so would fail to load in core apps.
Finally, the current way for writing audio drivers is via AudioServer
plugins that run sandboxed inside coreaudiod, implementing
AudioServerPlugInDriverInterface. I've done this before for writing a
driver for a nonstandard device entirely from scratch. I don't see an
obvious way to associate an instance of this with the already-existing
IOAudioDevice/IOAudioEngine instances implemented by AppleUSBAudio in
the kernel however. Except perhaps the CreateDevice() method which you
don't seem to need for a from-scratch device driver, but the header
docs and sample code comments imply this is for implementing a virtual
device for an AirPlay-like streaming interface, and I don't see how
I'd get my .driver bundle to be considered for that USB audio device.
Have I missed anything? Some other way, or some nuance that makes the
methods I've found work on recent macOS versions after all?
Thanks,
Phil
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden