Re: Echo cancellation

[New to following the w3 threads on webrtc, but not new to webrtc ...]

On Thu, Dec 8, 2011 at 8:59 AM, Marco Pracucci

> 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.
> What if the UA has a default behavior that tries to guess if EC should be
> on/off, but the app can override it?

I'm in full agreement here with Randell and Marco. I think it's great if an
app wants to offer a more global control over EC, but that global set of
'switches' can be far too global given that so much of what we do these
days is in a single browser. Giving control to both places is important
Bob Wolff
GoCast - Video broadcasting on the go! <>

Received on Friday, 9 December 2011 09:56:09 UTC