Re: Implementing a filter driver for a USB Audio compliant device
Re: Implementing a filter driver for a USB Audio compliant device
- Subject: Re: Implementing a filter driver for a USB Audio compliant device
- From: Bob Stuller <email@hidden>
- Date: Fri, 25 Aug 2006 13:11:57 -0400
Core Audio Folks, Greetings!
At 9:58 AM -0600 3/7/05, Mark Cookson (replying to someone else) wrote:
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
_______________________________________________
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