Re: HAL CFPlugin Audio Driver vs. IOKit Audio Driver
Re: HAL CFPlugin Audio Driver vs. IOKit Audio Driver
- Subject: Re: HAL CFPlugin Audio Driver vs. IOKit Audio Driver
- From: Jeff Moore <email@hidden>
- Date: Tue, 3 Jan 2006 16:07:10 -0800
On Jan 3, 2006, at 3:42 PM, Fabian Renn wrote:
i've programmed a kernel IOKit audio driver for a usb 2.0 audio
device and very unfrequent kernel panics are giving me a hard time.
I'm also experiencing performance problems. Searching through the
CoreAudio Frameworks i found out that an audio driver can also be
programmed in user space through a HAL CFPlugin. I checked the web
and found out that the iSight works like this and some Protools
stuff. Is it a good to idea to program a usb 2.0 audio device with
a HAL CFPlugin, instead of using an IOKit driver?
No. The user-land driver model is there as a last resort for devices
that just make no sense in the kernel. The iSight falls into this
category.
Digi's stuff uses the user-land model because they needed a radically
different IO model and had to handle all their own in-kernel work.
The user-land plug-in is simply a bridge to their own in-kernel
driver (I'm actually simplifying here, their situation is actually
more complex).
Is this API likely to change in the future? Will it be supported by
Apple in the future?
It has been through three revisions already and I'm positive it will
continue to evolve going forward. That said, the HAL makes every
effort to support all versions of this plug-in interface.
I already have a user space daemon that has a shared memory audio
ring buffer it keeps sending/recieving to the device over the
userspace usb interface. Also, i couldn't find much documentation
about writing CFPlugin based audio drivers; is there more? maybe
even source code?
There is no help beyond what is in the header and the questions you
ask here.
And why isn't it generally preferred to write audio drivers as user
space drivers ( for usb/firewire devices )? It would be a great
stability gain!
The primary reason is that writing a user-land driver is hard. You
are totally on your own. You have to fully implement with exacting
detail all the semantics that the HAL provides for IOAudio-based
devices. You will write several orders of magnitude more code and you
will still have compatibility issues (just look at this list's
archives and see the issues that folks have had). Non-IOAudio based
devices are also not eligible to be aggregated or have other nice
things done for them by the system. Writing an IOAudio driver
generally requires much less code and is actually much easier for
lots of devices, kernel debugging not withstanding.
Finally, user-land driver plug-ins generally take up way more system
resources than in-kernel drivers. So, while you don't panic the
system, you do cause it to use more memory, threads, daemons, etc.
and that actually ends up hurting over all performance, especially on
small machines.
So, to sum up kernel based drivers are:
1) generally easier to write because they require way less code
2) more compatible and more functional right out of the gate
3) require fewer system resources and so generally perform better
User-land drivers are:
1) harder to write due to the exacting semantic requirements of the
HAL API
2) good for devices that just don't fit into the kernel in a straight-
forward way
Obviously, you should use the API that fits better with what you want
to do. But IMHO, there's no reason why a USB 2.0 driver should be out
in user-land. It might make debugging a bit easier if it was, but I
think the drawbacks far out weigh that single advantage.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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