AppleUSBAudio Plugin Issues
AppleUSBAudio Plugin Issues
- Subject: AppleUSBAudio Plugin Issues
- From: Torrey Holbrook Walker <email@hidden>
- Date: Fri, 25 Aug 2006 16:09:47 -0700
Hi Bob,
AppleUSBAudio is most certainly not subclassable. Generally speaking,
on OS X a driver that starts with "Apple" could change at any time.
Only drivers that begin with "IO" try to preserve binary
compatibility , etc. from release to release.
To be honest, I've never tried to create a configuration app for the
plugin interface. I'll take a look at this next week and let you know
my findings.
Good luck! /thw
--------------------
Torrey Walker
CPU Audio Software Team
Apple Computer, Inc.
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