Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
AppleUSBAudio Plugin Issues
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AppleUSBAudio Plugin Issues



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




Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.