Re: [Bug 15747] New: Echo cancellation API

(Testing if reply-all updates bugzilla)

Questions not answered yet:
- to which audio streams does echo cancellation apply, if there are 
several? Should we ignore it and say "the implementation will do the 
best it can across all streams"?
- should the echo options be part of some other option object; 
alternatively should the mediaOptions be renamed to something more generic?
- is it correct to place this option on the PeerConnection?

On 01/27/2012 07:30 PM, bugzilla@jessica.w3.org wrote:
> 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;
> }
>

Received on Sunday, 29 January 2012 20:30:00 UTC