|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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
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.
Copyright © 2011 Apple Inc. All rights reserved.