- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Thu, 08 Dec 2011 10:33:12 -0500
- 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 control. 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 randell-ietf@jesup.org
Received on Thursday, 8 December 2011 15:35:26 UTC