Re: echoCancelation (sic)

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.


On Fri, Mar 28, 2014 at 11:50 AM, Jan-Ivar Bruaroey <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 :.
>
>