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.