Re: echoCancelation (sic)

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 :.