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/