Re: advice to associate custom signal processing with a device
Re: advice to associate custom signal processing with a device
- Subject: Re: advice to associate custom signal processing with a device
- From: Jeff Moore <email@hidden>
- Date: Sat, 24 Jul 2010 12:48:04 -0700
On Jul 24, 2010, at 3:32 AM, Iain McCowan wrote:
> This post is in follow-up to one I sent last year about associating custom signal processing with a specific USB audio input device, with reply from Jeff Moore (relevant bits below).
>
> I gave up trying to get my processing working in a kext plug-in - the main stumbling block being that I do frequency domain modifications so require FFT, which is not easily obtainable in kernel mode. (I use Intel IPP libraries for this currently - If anyone can point me to an FFT implementation that builds in a mac kext project out of the box, that would perhaps get around my issues).
I'm not a signal processing expert, but near as I can tell math is math. There should be nothing stopping you from compiling the SSE instructions that result in doing an FFT in an audio driver in the kernel. For example, our built-in driver does a lot of processing on the signal going to the built-in speaker on our machines for protection. I don't know if any of that is FFT-based though.
That is not to say that there aren't a few hassles. The biggest is the kernel environment itself. This cuts off access to all the user-land APIs. You can't link in any shared libraries, etc. It also makes debugging a tad trickier and increases the cost of a bug as it can panic the system.
> So I am revisiting the problem and from recent posts on the list think that perhaps what I need to do is implement a user-land driver based on the SampleHardwarePlugIn example. From other posts, Jeff seems to recommend this for cases that are a bit out of the ordinary.
>
> I have looked through the sample code and have a couple of basic questions to help me get started:
>
> 1) How do I actually associate the user-land HAL plug-in with my specific USB device? Is this done separately using e.g. the SampleUSBAudioOverrideDriver example to specify the "IOAudioEngineCoreAudioPlugIn" ?
Not at all. If you are going this route, you cannot use the USB audio class driver. So, in addition to writing the user-land portion of the driver to hook into the HAL you will also need to write the bits that talk to the device over the USB bus. Since you are in user-space, it may be possible to do this with the user-space interface to the USB controller. But I don't know anybody that has tried doing that.
> 2) If I associate the plug-in with my device as in 1, if all I want is to add custom processing to samples coming from my microphone, does this mean I just then have to modify the sample buffers in e.g. "PreProcessOutputData"? And can otherwise leave the SampleHardwarePlugIn code mostly unmodified?
See above. Going this route is a tall order for a piece of USB Audio hardware that is class compliant. That's why I suggested putting your processing in the kernel in the first place.
> thanks,
>
> Iain.
>
>
> This processing would need to be done in the kernel as part of your driver's mix-and-clip processing. That's really the easiest place to put it. I believe that is where the USB Audio driver's plug-ins patch into the signal path, so you should be good to go in that regard.
>
>
> I have attempted to extend the SampleUSBAudioPlugin kext example to achieve this, however I need FFT and vector math routines. These don't seem to be available in the Kernel or IOKit frameworks (I see only a few limited vector math operations), and I am not sure that it is possible build or run a kernel extension linked to other frameworks or libraries with FFT and vector routines, such as Intel IPP library or the Accelerate Framework (vDSP).
>
> Obviously, you can't link in user-land frameworks or shared libraries. That just won't work. You need to either use the facilities the kernel provides, which includes a limited version of the routines in Accelerate.framework, or you need to build all the code you need for your signal processing into your kext.
>
> One thing to be aware of is that kexts don't really allow for floating point code to be built into them. Typically what audio drivers do to work around this is to build all the floating point code into a static library that is linked into the kext. You can see an example of doing this in the AudioReflectorDriver in /Developer/Examples/CoreAudio/HAL.
_______________________________________________
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