[Bug 15747] New: Echo cancellation API

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15747

           Summary: Echo cancellation API
           Product: WebRTC Working Group
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: WebRTC API
        AssignedTo: public-webrtc@w3.org
        ReportedBy: rjesup@jesup.org
                CC: public-webrtc@w3.org


Proposal for the API to control Echo Cancellation in WebRTC:

We need options to enable and disable echo cancellation in WebRTC.  By
default, echo cancellation should be on for audio channel selections
that imply the likely possibility of echo, and off for ones where echo
is unlikely (audio input and output both going to a headset).  The
system would be allowed to change the EC state in response to input
routing or mute changes, or even to changes in the captured signal;
when that happens the onmediaoptionschange notification would occur.

The app could set the echoCancellation state.  Open Question: should
this block future automatic changes?  If so, should there be a way to
restore them, perhaps by using a tri-state setting (on, off, auto)?

Since we should future-proof this API against needing more options in
thie future, we will put the API for controlling echo cancellation in
a media options object.

Add:

interface MediaOptions {
   attribute boolean echoCancellation;
}

Open issue: should we expose the amount of echo cancellation or
expected echo levels?  I know the GoCast people thought this might be
useful.

If we add it, it should be relatively generic and not firmly tied to
the underlying implementation we currently have (and there are two in
the webrtc code drop):

  attribute float expectedERL;

Basically, the aggressiveness of the echo cancellation should be
dependent on the expected ERL.  This would map to the 'routing'
parameter in the webrtc.org 'mobile' EC block, and maybe to the
'SuppressionLevel' in the regular EC block.  (Or do we need to
separate the concepts?)  Alternatively, we could expose something
closer to the enumerated API in webrtc.org code.


Add to PeerConnection:
{
...
    attribute MediaOptions mediaOptions;
    attribute Function? onmediaoptionschange; 
}

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.

Received on Friday, 27 January 2012 18:30:59 UTC