W3C home > Mailing lists > Public > public-webrtc@w3.org > December 2011

Re: Echo cancellation

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Thu, 08 Dec 2011 18:14:39 +0100
Message-ID: <1323364479.11343.383.camel@altostratustier>
To: Randell Jesup <randell-ietf@jesup.org>
Cc: public-webrtc@w3.org
Le jeudi 08 décembre 2011 à 10:33 -0500, Randell Jesup a écrit :
> Except that a browser interface means it has to be in the chrome in some 
> manner, which leads to all sorts of discoverability problems. 

My understanding is that we'll have already a good chunk of the UI
managed by the browser (to select a given audio device, a given video
device, to turn on/off a given device), so having that UI deal with echo
cancellation doesn't seem like a bad idea.

>  I don't 
> have a problem with being offered in chrome (though I might not mandate 
> it), but I think having the application be able to offer the option 
> within their UI (and possibly explain it, or use something to decide 
> when to suggest it to a user) is a plus.  Also, if it's in their UI, 
> they control where it shows up and what it looks like, and they don't 
> have to say "if your partner hears clipping or odd-sounding audio, turn 
> off EC.  To do this, on IE go here..., on Firefox go here..., on Opera, 
> on Safari, oh, and by the way, if you're on a mobile device....".

Yeah, I can see that having to guide the user through a specific UI
isn't great; but how frequently does one have to deal with this? Is this
something that we need for the 1st release of Web RTC, or can this be a
feature that a later release could address?

(anecdotically, I know I've never turned echo cancellation on or off in
any video/audio communication system I've used)

> Another use-case might be where it knows (via several possible 
> mechanisms) the other side is muted; it knows there's no echo to cancel.

I think the right way to deal with this would be for the Web app to let
the browser know when the other side is muted (assuming using mechanisms
that the browser doesn't have access to directly).

> I also see no security reasons to avoid giving the app access to the EC 
> control.

I can't think of any either; it's more a matter of reducing the scope of
what we need to develop (or get others to develop), so that we can ship
something earlier.

Received on Thursday, 8 December 2011 17:15:03 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:26 UTC