[wdmaudiodev] Re: Intercepting Audio Data Going to Sound Card
- From: e-t172 <e-t172@xxxxxxxxxxxx>
- To: wdmaudiodev@xxxxxxxxxxxxx
- Date: Thu, 17 Jun 2010 21:38:36 +0200
On 17/06/2010 20:53, Tim Roberts wrote:
On 6/17/2010 11:29 AM, e-t172 wrote:
On 17/06/2010 20:15, Tim Roberts wrote:
It's actually possible to install
a GFX APO on your own, but you can't release such a thing unless you
also supply the audio card driver.
Why?
The Microsoft philosophy is that APOs are an extension of the hardware,
and hence should only be installed with the driver. This is all part of
the "who's in charge" issue. They believe there should be nothing in
the audio path that wasn't either installed by the hardware vendor or
requested by an application. Whether I agree with it or not, I do
understand the motivation.
Well, as long as we're just discussing "philosophy", I can still release
my "standalone" sAPO... right?
Perhaps the trickiest part of the GFX APO is installation. Normally,
the name you assign to your APO becomes the name of the audio device in
the control panel.
No it doesn't. The name of the audio device in the control panel is
stored in the "{a45c254e-df1c-4efd-8020-67d146a850e0},2" registry value
under the "Properties" subkey of the audio device. The name of the APO
is stored in the "{b725f130-47ef-101a-a5f1-02608c9eebac},10" value under
"FxProperties", but it doesn't seem to be documented anywhere and it
doesn't even appear in the UI. In fact, it doesn't seem to serve any
real purpose, at least for now. Besides, the sAPO still works if you
remove the registry value.
Installation is not really a problem. You just need to develop some
trivial application which will allow the user to choose which audio
devices he wants to use with the APO. Then it's just a matter of
replacing two registry values and restarting a service. I even think
it's possible to call the original APO (the one bundled with the audio
device driver) inside the new APO, which means the original filter would
still be available to the user along with the new filter.
That's why I'm currently rewriting my filter as a GFX sAPO.
I will be curious to hear of your experience with this. It's certainly
something that a lot of people want to do.
From here it's looking quite good, but I didn't implement the APO
itself yet. The only thing that could be issue is the real-time
requirements: in the APOProcess() method (the main method where you're
supposed to actually filter the audio data), you're not supposed to use
any system calls or even touch any pageable memory. Problem is, I won't
be able to follow these guidelines because the actual processing code is
already written in a library, and making it "real-time compliant" would
not be an easy task. So I'll just write it normally and see what
happens. This doesn't seem to be a hard requirement, since the "swapapo"
sample in the "sysfx_reuse" package actually writes to a log file each
time APOProcess() is called, without causing any perceivable problems.
When my filter is finished (if it is ever finished), I will distribute
it under a GPL license, so you'll be able to take a look at it if you're
curious.
--
Etienne Dechamps / e-t172 - AKE Group
Phone: +33 6 20 41 09 29
Other related posts:
