[wdmaudiodev] Re: AEC in Vista
- From: "Jerry Trantow" <Jerry.Trantow@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
- To: <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Wed, 4 Oct 2006 15:17:17 -0500
I've been lurking on this thread but I'd like to understand the viewpoint
"inherently built into OS APIs" vs "better solution than inserting 3rd party
processing". I hope this means that MS will provide a default AEC for basic
mic arrays and an OS API to seamlessly allow overrides with 3rd party
processing for custom arrays. A basic AEC that works for Joe six pack if a
great idea, but there are special uses for improved arrays and algorithms.
Keeping up with the features and performance of 3rd party hardware and
special cases isn't within the OS domain, providing an override API should
be.
Think about the current SRC. I think it's great that MS provides a SRC
implementation for the majority of conversions, but I really wish I could
replace the darn thing with an improved algorithm when I am using my sound
card for signal analysis. Instead, I have to careful to pick my settings to
avoid using the MS SRC or I get poor results with tones. (and there is no
good reason a 48khz device can't downsample to 8khz without shifting the
frequency of a tone like the current SRC does)
I can't wait to try the Vista AEC. But, AEC isn't a one size fits all
software issue. Laptop VoIP requirements differ from a large room
conference call setup with multiple speakers. Special applications will
need to tailor the AEC software for the acoustics. I expect needing an API
to insert my own AEC code for specialized applications. If you don't plan
for a way(device specific) to override the built in AEC, we'll get stuck
with either work around hacks or the lowest common denominator of
performance, neither of which is a good policy.
-----Original Message-----
From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Hakon Strande
Sent: Wednesday, October 04, 2006 2:24 PM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: AEC in Vista
Tim,
(I am not answering for Shuba but she is on vacation so you get my views
instead)
Another viewpoint could be that AEC should really not be a vendor provided
feature or an attribute of the microphone or any other capture hardware but
should rather be inherently built into OS APIs because it is so necessary
for some applications to function and because applications don't want to
rely on the user having a certain driver/filter driver/APO installed or
specific capture hardware connected.
Enabling applications (who one could argue owns the total user experience
for that application and should be able to control it) to make use of a
universally known and always present/available AEC may be a better solution
than inserting 3rd party processing into the pipeline that the application
may not even be aware of, the application may not be able to control or that
may not be there on all systems.
Please email us directly if you want to continue a philosophical discussion
about the different approaches to value-add enabling in Windows Vista.
Sincerely,
Hakon Strande (hakons@xxxxxxxxxxxxx)
Program Manager Integrated, Internal, External, and Wireless Audio Devices
MediaTech/DMD/Windows Client/Microsoft
_____
From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Tim Roberts
Sent: Wednesday, October 04, 2006 10:20 AM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: AEC in Vista
Shuba Iyer wrote:
AEC and microphone array processing in Vista are application graph features.
So it is up to the application to use the feature or not.
You know, the more I think about this statement, the more I think this
position is completely wrong.
AEC is perhaps "the" canonical feature that one would want to use globally.
As a user, I'm not going to think about AEC as an application add-on.
Instead, I'm going to think about AEC as an attribute of the microphone
array. If I have installed some kind of AEC, then I want echo cancellation
in every application that uses that microphone, whether it be wave, DSound,
or WASAPI.
I've been using Sound Recorder as an example, but that's the wrong example.
With the policy you have described, there is no way to use an AEC-enabled
microphone with NetMeeting, which is one of the apps where I would most want
echo cancellation. In fact, if I am a vendor supplying my own AEC DMO
following your model, there is no way to have it get used by any
applications other than the ones I have written myself.
That ain't right. Have I misunderstood your position?
--
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.
Other related posts:
