Tim, I believe in the past we saw several XP conferencing apps actually implement AEC inside the app (as a response to the less than stellar low-level AEC in Windows XP which is probably the most disabled Windows component of all time) and that trend was one we wanted to encourage for these very app centric audio processing needs by providing high quality algorithms in Vista for applications to instantiate that may not have their own AEC/Mic Array "crack engineering teams". In any case AEC is to us in Windows Vista an application feature as it has been on Windows XP for quite some time in some very popular applications and if a specific legacy app does not have AEC then I do think the people you hear from will be able to find an app that does have this feature, or the app will receive a Vista update...especially if starving children are involved. J Jokes aside, one could argue that a better AEC/Mic Array algorithm will find its way into more Windows users hands faster if it is a feature of a popular communication application than if it is supplied as a "go-find-it-on-OEM-web-site" driver update to one of several hundred different custom OEM audio device support solutions. If new and shiny algorithm X isn't applied by application A then it is not IMO the responsibility of the infrastructure to make that (mis)match possible because application A would not control or know that the experience has changed and does not control any of the aspects of the "new" algorithm. In most cases it would not even know two AEC's where running. There is a reason applications implements their own AEC - they want complete control over the properties of the algorithm, properties that can't be accessed when the algorithm is located in the low-level OS infrastructure, in the driver or in hardware so it is IMO the owner of application A's job to make the business decision that algorithm X is better for their customers than the one they employ now. If absolutely necessary it is theoretically possible to use a capture LocalFX insertion point and the render GlobalFX insertion point in tandem to achieve system-level AEC for a specific logical device but this is not recommended. Also, the timing info that needs to pass between the two sysfx APO components must use proprietary interfaces to share time stamps as there is no native interface for that. Filter drivers won't work when the miniport driver is based on the WaveRT driver model which will likely be the driver model of choice for the logo compliant audio solutions in Windows Vista PCs. The paradigm shift is probably more related to the fact that in the past anyone could insert audio processing components into the Windows audio stream path without the knowledge of the system vendor, the application, the OS or the audio device manufacturer, all with a stake in the user experience. With the desire to achieve greater discoverability, transparency and user/application control of the audio stream path comes restrictions on who can provide and where they can insert the external components that affect the Windows' users streaming audio experience. This is a natural evolution IMO towards more predictability that in turn provides more reliable application experiences on Windows. Unfortunately I am not able to discuss this issue further here (as this is probably spam to most of our esteemed mailing list subscribers) but please contact me off line if you have any further comments. Sincerely, Hakon Strande <mailto:HakonS@xxxxxxxxxxxxx> | Windows Sound Team PM | (p) 425.705.0637 From: wdmaudiodev-bounce@xxxxxxxxxxxxx [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Tim Roberts Sent: Tuesday, March 20, 2007 3:41 PM To: wdmaudiodev@xxxxxxxxxxxxx Subject: [wdmaudiodev] Re: AEC and Noise Reduction Hakon Strande wrote: There is no existing AEC GFX module. AEC among other audio processing is an application graph audio processing object (DMO) in Vista and does not live in the lower-level system effect infrastructure which is reserved for certain types of common audio hardware vendor value-add. Apparently, I had developed a fundamental misconception in my brain. I just went back to reread the sysfx.doc white paper, and it certainly agrees with you. My mistake. For now you either choose to be a Windows friendly device in which case you leave AEC, Mic Array, etc processing to the application that the user is using or you choose to build a device that may only work well with Windows applications (that make use of the Vista app graph processing algorithms) if you turn of features of the device (which device designers could at least allow the user to do as a compromise so as to not render the device semi-useless/troubled when used with some Vista applications). But isn't there a fundamental limitation here? Let's say, for example, that ABC Company releases a Vista-compatible conferencing app tomorrow, using MicArray and AEC processing. Now let's say that DEF Company independently develops a better MicArray/AEC algorithm. If I, as the user, want to use DEF's algorithm with ABC's app, there doesn't seem to be any way to do that. The people who are contacting me are mostly interested in existing ("legacy"?) video conferencing apps, which won't have AEC in their processing at all. Since they have to be able to sell their products to feed their children, they're going to end up implementing hacks that combine filter drivers for the input side and GFX APOs for the output side (despite not owning the output device), and tying them together with some kind of yet-to-be-determined magic. That's a terrible answer, but I haven't yet heard any of them come up with a better solution, short of going out of business. -- Tim Roberts, timr@xxxxxxxxx Providenza & Boekelheide, Inc.