Re: coreaudio-api digest, Vol 2 #876 - 13 msgs
Re: coreaudio-api digest, Vol 2 #876 - 13 msgs
- Subject: Re: coreaudio-api digest, Vol 2 #876 - 13 msgs
- From: Stefan Werner <email@hidden>
- Date: Sat, 11 Oct 2003 16:38:19 +0200
Hi!
Subject: AudioHardwarePlugIn questions
From: Kris Daniel <email@hidden>
To: email@hidden
1.) Am I interpreting AudioHardwarePlugIn.h correctly, in that I can
develop my own CFPlugIn that acts as an audio device for the AudioHAL?
AudioHardwarePlugins will appear to applications like they any other
audio hardware device. But there are significant differences to kernel
drivers: An AudioHardwarePlugin will run in a separate instance for
every CoreAudio application that is launched. The plugin will have to
take care of communication with the application, e.g. answering
requests about the supported audio formats. Your plugin will live in
the respective application's memory space and unless you explicitly
change that, will also have the respective host's process priority. A
kernel driver, in contrast, will be instanced only once with kernel
priority and get readily mixed buffers from the HAL. It will not have
to talk to the applications themseleves, it will only report its
capabilites once to the HAL and the HAL will take care of communicating
with the application.
2.) Is there additional documentation regarding how to develop this?
Not that I had seen any. I can send you some sample code if you like, I
have an experimental driver running and the Jack developers are having
an AudioHardwarePlugin Jack client in beta.
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 moved my project from an AudioHardwarePlugin to a kernel space driver
recently. The main reason for me was that the HAL plugin was instanced
for every application, where the kext way of running only one instance
of my driver was much better suited for my purpose. There were also
performance improvements, but that could be simply due to the fact that
my user space plugin was always compiled with debug symbols and no
optimizations whatsoever. The big disadvantage of a kext is that you
are in kernel space: You are limited in your choice of system functions
and frameworks you can use and every mistake you make is "lethal" - be
prepared for a kernel panic for every NULL pointer you didn't check,
every buffer overflow, every division by zero. A faulty HAL plugin will
only crash the host app but not the system. If you want to, you can
write a user space version first for prototyping and once you got it
running, rewrite it as a kext.
Stefan
--
http://www.keindesign.de/stefan/
_______________________________________________
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.