Re: echoCancelation (sic)

On 3/28/14 7:02 PM, Justin Uberti wrote:
> I think it's fine to require that you specify ec:false if you don't 
> want AEC.

Of course, but if you don't should gUM return ONLY mic's that have AEC?

If you say yes, you would never get my high-fidelity mic, even if your 
other constraints begged for it, and it wouldn't be obvious why. I think 
that's a problem.

If you say no, then the meaning of default seems unclear.

Constraints always narrow, so we have to start completely unconstrained, 
I think, or it breaks down.

So constrants can't have defaults.

Sources have defaults, and could perhaps be mandated to default to 
ec:true if they support it. Furthermore, UAs could be mandated to prefer 
ec:true sources.

E.g.pseudo-code (leaving out mandatory/optional for brevity):

  { audio:true; } // result.getSettings().ec == true if supported
                  // would only pick non-aec mic as last resort

  { audio:{ ec:true; } }   // result.getSettings().ec == true
  { audio:{ ec:false; } }  // result.getSettings().ec == false

.: Jan-Ivar :.

> The penalty for it accidentally being on is small, but the penalty for 
> it accidentally being off is large.
>
>
> 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.
>
>     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.
>
>     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 :.
>
>


-- 
.: Jan-Ivar :.