Re: AudioHardwarePlugIn questions
Re: AudioHardwarePlugIn questions
- Subject: Re: AudioHardwarePlugIn questions
- From: Jeff Moore <email@hidden>
- Date: Fri, 10 Oct 2003 15:07:00 -0700
On Oct 10, 2003, at 12:16 PM, Kris Daniel wrote:
I'm tasked to develop a CoreAudio driver for a USB device. I know
that with the I/O Kit USB Family I can communicate with the device
from usermode. Additionally, it seems encouraged to avoid kext
development as much as possible, but reading the "Writing Audio Device
Drivers" document, it seems that audio device drivers are kexts.
Poking around in the CoreAudio Framework, I've found the
AudioHardwarePlugIn.h header file, which is an "API for the CFPlugIn
that implements an audio driver for the HAL from user space". This
sounds like exactly what I should be doing. Here's a few introductory
questions:
1.) Am I interpreting AudioHardwarePlugIn.h correctly, in that I can
develop my own CFPlugIn that acts as an audio device for the AudioHAL?
Yes, but this is reserved for very unusual cases. It is not intended
for use for most devices as kernel drivers provide superior
functionality.
2.) Is there additional documentation regarding how to develop this?
No, but if you think your hardware doesn't lend itself to being done in
the kernel, then you should get in touch with Developer Relations and
start a dialog.
3.) Where would I install the CFPlugIn to, in order for the system to
recognize its presence?
HAL plug-ins are installed in /Library/Audio/PlugIns/HAL.
4.) (Possibly off-topic) the device additionally supports MIDI, which
is also done through a CFPlugIn. Is it possible to develop a
system-wide accessible user space device driver, which communicates
with both the MIDI CFPlugIn and the AudioCFPlugIn, and if so, how
should that be bundled? Is there any documentation for such a user
space driver?
MIDI drivers are user land entities for the most part. There is
documentation in /Developer/Documentation/CoreAudio/MIDI and sample
code in /Developer/Examples/CoreAudio/MIDI.
5.) Do audio device driver kexts offer superior performance due to
residing in the kernel, or is there any compelling reason to choose a
kext over a user space driver/CFPlugIn?
I don't know that being in the kernel gets you better performance from
a CPU utilization point of view, but it does allow your device to be
presented through the HAL in a more consistent manner. Further, a user
land USB or FireWire driver can only support one process accessing it
at a time. This greatly diminishes the usability of the device on the
system since device sharing is a pretty deeply ingrained behavior on
Mac OS X. Plus, I would also estimate that you'd end up writing a lot
less code for a kernel driver than you would with a HAL plug-in,
especially for a USB device.
So, audio is one of the rare exceptions to the guidance about when to
write a kernel driver. In this case, go ahead and do it if at all
possible.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.