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 10:33:12 -0500
Message-ID: <4EE0D8B8.8060406@jesup.org>
To: public-webrtc@w3.org
On 12/8/2011 7:48 AM, Dominique Hazael-Massieux wrote:
> Le jeudi 08 décembre 2011 à 12:02 +0100, Stefan Hakansson LK a écrit :
>>> Reading through the use cases, none of them seems to suggest a case
>>> where the Web app needs to have specific control on echo cancellation.
>>> Can anyone think of a reason why it should? Shouldn't this be something
>>> that "just" happens whenever audio streams are exchanged? or should it
>>> only happen for some audio streams?
>> My default view is the same (i.e. just happens). But this has not really
>> been discussed, and there can be reasons for giving control:
>> * The echo canceller introduces a lot of clipping (or other artefacts),
>> and there is no need since the user uses a head set
>> * The echo canceller consumes a lot of CPU (and is not needed)
>> It can be noted that if you go into "settings" of many commercial
>> clients today you get the option to disable the EC
> I think these reasons could all be handled (and probably be better
> handled) by the browser offering a user interface, rather than by each
> Web app having to deal with it.

Except that a browser interface means it has to be in the chrome in some 
manner, which leads to all sorts of discoverability problems.  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....".

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 also see no security reasons to avoid giving the app access to the EC 

I'd vote strongly in favor of letting the App turn EC on and off.

>>> I'm not clear if there is anything that we need from the Audio WG on
>>> this bit, if it is all to be handled on the browser side. We may need to
>>> have a flag on audio tracks to enable/disable echo cancellation (if
>>> there are indeed use cases for that), but I don't think we should expect
>>> each Web app to manually use the audio API to do echo cancellation.
>> Agree!
> OK; probably worth including in our feedback to the audio WG if
> consensus emerges on this.

Randell Jesup
Received on Thursday, 8 December 2011 15:35:26 UTC

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