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
<marco.pracucci@spreaker.com>wrote:

> 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
IMHO.
-- 
Bob Wolff
~~~~~~~~~~~~~~~
GoCast - Video broadcasting on the go!
www.GoCast.it <http://www.GoCast.it%20>