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

Re: Echo cancellation

From: Randell Jesup <randell-ietf@jesup.org>
Date: Thu, 08 Dec 2011 17:11:30 -0500
Message-ID: <4EE13612.30104@jesup.org>
To: public-webrtc@w3.org
On 12/8/2011 12:14 PM, Dominique Hazael-Massieux wrote:
> 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.

Managed?  Only sort of, and mostly at "open" time (i.e. a pop-up similar 
to a Browse <input> item.)  We need to have certain things handled by 
the browser (popup for consent), and to allow the user to force them 
off, but so far that's about the limit of the requirements on chrome. 
(An implementation might have more - mute, switching inputs, etc - but 
it's not required.)

>> 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?

I see this as quite trivial; I see little or no advantage in waiting.  I 
think in practice implementations would provide it, but 
non-standardized.  On discuss-webrtc there are already questions about 
"how do I turn EC on/off?".

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

Depending on the hardware you have (many laptops have bad EC 
characteristics, some headsets do) you may need to turn on/off EC.  I've 
seen it fairly often done in Skype or Vidyo.

>> 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).

Ok, but it's more complex than that at times (for example, if a youtube 
video is playing you may want to keep EC on, so long as the EC code can 
see the youtube audio going out).

>> 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.

The scope reduction seems to be virtually nil to me.  I could code it up 
faster than writing this email... ;-)

-- 
Randell Jesup
randell-ietf@jesup.org
Received on Thursday, 8 December 2011 22:13:44 UTC

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