The Mac doesn't have a concept of filter drivers, so that's not
going to
work...
However, when I updated the AppleUSBAudio driver for 10.3.x (where
x > 3, if
memory serves), I added the ability to have a "plug-in kext"
operate hand in
hand with AppleUSBAudio, specifically for the purpose of doing DSP
work for
input and output. The plugin kext is a simple kext with some
basic entry
points that will be loaded and called by AppleUSBAudio.
I left Apple before I really got a chance to document, though I
did send a
write up and sample code to Jason Seng in Developer Technical
Support.
If you're adventurous, I suggest that you download the latest
AppleUSBAudio
driver and look for "mPlugin". You'll find all the instances of
where
AppleUSBAudio calls the plugin and you should be able to figure
out what to
do from there.
Good luck, and let me know how it goes! I'm not aware of anyone
actually
using this functionality (though the sample plugin kext worked, so
I'm
pretty sure you can get it to do what you want), so you might be
the first.
:-)
Ahhh.... Looks perfect. But the easy way out is usually mined,
right?
He is referring to USBAudioPlugin which looked perfect for my
project. My plugin would load for our particular USB-audio input
device, we could operate on the samples as they were acquired by the
device but before they went to the client, we could set our
configuration app to let users control some of our features....
except, unless I missed it, I don't see a hook for the plugin to
receive the configuration app's device requests, in particular the
custom ones that the plugin is interested in. Has anyone run into -
and overcome! - this limitation?
Three possible approaches occur to me. The first and most obvious is
to subclasses or clone AppleUSBAudio into a device-specific driver
and do everything and more that was planned for the plugin. The
question there: Is AppleUSBAudio subclassable or would I need to
clone it?
The second approach depends on AppleUSBAudio being subclassable. In
that approach, I subclass AppleUSBAudio & add functionality for the
plugin to get first shot at device requests & then proceed with the
plugin as originally planned. This approach is only worthwhile if
AppleUSBAudio is subclassable.
The third approach was suggested when I noted that the plugin is of
type IOService which is a subclass of IORegistryEntry. That would
suggest that it should be accessible via the IORegistry. Does it
sound feasible to communicate with the plugin via properties? Or is
that only possible when a workloop & command gate is part of the
picture.
As you can tell, I am quite new to the kernel side of Core Audio &
could use some guidance.
Peace,
Bob
--
Ignorance more frequently begets confidence than does knowledge.
- Charles Darwin
