[wdmaudiodev] Re: AEC and Noise Reduction
- From: Hakon Strande <hakons@xxxxxxxxxxxxxxxxxxxxx>
- To: <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Tue, 20 Mar 2007 17:05:30 -0700
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.
Other related posts:
