- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Sun, 29 Jan 2012 21:29:28 +0100
- To: bugzilla@jessica.w3.org
- CC: public-webrtc@w3.org
(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