[wdmaudiodev] Re: Device neutral GFX
- From: Tim Roberts <timr@xxxxxxxxx>
- To: wdmaudiodev@xxxxxxxxxxxxx
- Date: Tue, 02 Mar 2010 10:36:18 -0800
Robert Bielik wrote:
> Ok, so in "theory", would it be possible to: Register my APO (adding
> appropriate registry keys under .../AudioEngine/AudioProcessingObjects
> etc.), then have a utility enumerate the logical audio devices, and
> add my GFX APO under .../DeviceParameters/FX/N/#PostMix for each
> selected device? (the utility would then be needed if a new audio
> device is added, or a USB audio device is moved to another USB port)
Yes. Are you beginning to sense the pain level yet? It's going to get
even higher.
> Then theoretically the APO should be instanciated for the given
> devices, no? (given of course that the APO is signed, which then of
> course is a matter on its own...)
There are official white papers that describe how to work around the
signing issue for your testing.
> Given the constraint that APOs needs to be signed (through WHQL), I
> fail to see the logic to limit the possibility to install a GFX APO
> only to a specific hw device. I can immediately see the benefit
> businesswise to
> let ISVs be able to create/distribute/sell custom GFX APOs that are
> universal to the audio subsystem.
Whether or not I agree with it, I can tell you the philosophy as I
understand it. Up through XP, the Microsoft audio team was getting
terribly beat up because sophisticated audio applications and
sophisticated audio hardware could never rely on having a "pure" path
from hardware to application and back again. Latency was poor and
(worse) unpredictable. Throughput was unpredictable. This was, in no
small part, due to people who insisted on installing algorithm filters
in the audio stream, without the knowledge of either the application or
the hardware.
So, they made the decision to stop that. The application is now in
complete control of its audio path. The hardware is in complete control
of the services it provides. No one has the authority to interfere with
that. There are certainly people like you want the ability to insert
their clever, proprietary filtering algorithm in the global output path,
but that's a latency and bandwidth load that some applications simply
cannot afford. They know what they need -- you don't. Microsoft has
chosen to exclude you from the game.
So, you have two officially blessed paths. You can work with
application vendors to have them insert your filtering in their
application audio graphs, or you can work with a hardware vendor to
offer "filter-enhanced audio processing".
Again, I'm not arguing whether this is right or wrong. One of my
clients has been burned by this very issue. Thanks to a length, lively,
and very much appreciated debate with the audio team, I have a better
understanding of the problem they were trying to solve, and I understand
how they came to this decision. It is what it is.
> How does it work for the system supplied APOs? Are each IHV required
> to add an entry in the .INF to enable them? I've searched all .INF in
> my system and none mentions WMALFXGFXDSP.DLL and yet there is an entry
> in the registry that links to the system APOs. Is this "automagically"
> done by Windows upon installing an audio driver?
There's a white paper that describes this. If an IHV supplies an APO,
it is required to wrap any corresponding system-supplied APO.
http://www.microsoft.com/whdc/device/audio/Vista_SysFx.mspx
--
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.
******************
WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx
URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/
Other related posts:
