Re: echoCancelation (sic)

On 3/28/2014 7:02 PM, Justin Uberti wrote:
> I think it's fine to require that you specify ec:false if you don't 
> want AEC. The penalty for it accidentally being on is small, but the 
> penalty for it accidentally being off is large.

I agree.  I was going to suggest that if not specified, the UA can 
choose (or change it dynamically).  However, thinking it through, while 
there are some small advantages to that, the downside is 
unpredictability to applications.  The AEC should do little in a 
"recording" case other than waste cycles (which it will do), so there's 
little downside to enabling it by default.


Analysis (if anyone cares):
There are two primary uses for getUserMedia:  one, to feed into a 
PeerConnection for a two-way call, the other to feed into some type of 
recording or analysis.

There are a few typical situations: headset/mic (minimal echo), headset 
w/ remote mic (no echo), speakers with headset mic (moderate echo), 
desktop speakers with remote mic (USB Webcam) (moderate echo), laptop 
speakers with laptop mic (high echo, except for some systems with 
built-in or driver AEC).  By far the most common would be headset 
(low/no), laptop speakerphone mode (high), and desktop speakerphone mode 
(moderate).

Lastly, there may be other sounds playing from the browser/computer or 
not.  The UA may or may not be able to cancel these with an AEC.

For recordings, we generally don't care about (and usually don't need) 
AEC with the rare exception of a UA that can cancel other audio, and 
you're doing something like recording karaoke (and there it's best to 
use a headset unless in a group).  It may not hurt much (if at all) to 
have it on, however, since it won't see a playout signal normally.  On a 
power-constrained device avoiding AEC when it's not needed is a small 
win, so off for recordings may be a win.

For conversational use (PeerConnections) you want AEC for all but the 
headset case.  For that one, it can go either way; I've seen AECs get 
very, very confused by someone holding a cord-mic in their hand and 
waving it around while talking, causing them to "VoIP"/cut-out 
intermittently.  Admittedly it *shouldn't* do that, but I've seen it.  
In that well-known system at least, turning off AEC when on headset was 
definitely a win, quality-wise.  (and one needed to do so in mid-call, 
of course.)

The net result would be: Recordings: doesn't matter much, so On by 
default (except maybe on Mobile).  Peerconnections: On by default, 
unless told by the user to disable (off), or you know they're on a 
headset (maybe off).  However, the advantage of all of this is small, 
compared to the predictability benefit.

I'll note this is generally semantically a *setting* more than a 
*constraint*, though on Android you might have narrow-band-only HW AECs 
available or WB with software AEC.

A few inline remarks below:

>
> On Fri, Mar 28, 2014 at 11:50 AM, Jan-Ivar Bruaroey <jib@mozilla.com 
> <mailto:jib@mozilla.com>> wrote:
>
>     On 3/28/14 12:12 PM, Harald Alvestrand wrote:
>>     On 03/28/2014 05:04 PM, Justin Uberti wrote:
>>>     It would be good to document this explicitly in the spec.
>>
>>     I think we should document explicitly that the default is true
>>     (on). Any objections?
>
>     I think defaults on constraints are confusing unfortunately,
>     because of the two contexts: source-selection vs. track-apply.
>
>     It seems up to a UA to implement AEC either using software or
>     hardware if available (some mics/OSes offer it, which, being
>     closer to the recording source, may have an advantage over software).
>
>     So I think what you get depends on what's available:
>
>     For argument's sake (and this is to work out the logic, so
>     never-mind how obscure this is):
>
>     Say my browser doesn't have software AEC for some reason
>     (low-power device), but has two different mics: one low-fidelity
>     mic does AEC in hardware, and another high-fidelity one cannot.
>

This will happen in some handsets.

>
>     Your may want the high-fidelity mic and have constraints that say
>     so. But if we're to imply "echoCancellation:true" as an implicit
>     constraint, then that might hinder you getting what you want.
>

Note that this would only be an issue with a UA with no software AEC.  
Specifying a *hardware* AEC is an entire additional kettle of fish.

>
>     Specifying echoCancellation:false might work, but that means
>     "avoid aec" rather than "I don't care about aec", so that doesn't
>     correctly counter-act an implied true.
>
>     So I think constraints are absent by default rather than having
>     default values.
>
>
>>     Query: If a platform doesn't support echo cancellation, in either
>>     hardware or software, would it make sense to return "false" as
>>     the only value for this constraint in capabilities()?
>
>     Hmm, can we return more than one value for booleans in
>     getCapabilities()? I thought it as just a boolean ("I can do aec"
>     vs. "I can't".
>
>     .: Jan-Ivar :.
>
>


-- 
Randell Jesup -- rjesup a t mozilla d o t com