- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Sat, 11 Aug 2012 01:03:23 -0400
- To: public-webrtc@w3.org
On 8/10/2012 7:51 PM, Martin Thomson wrote: > On 10 August 2012 09:03, Randell Jesup <randell-ietf@jesup.org> wrote: >> The incoming track would be for local echo. Using an audio element in the >> app for local echo invites the possibility of the local tone not being >> echo-cancelled and leaking into the outbound stream (especially if the >> developer guesses wrong at the length/start-time of the outgoing 'tone'), >> causing possible double-detection in an IVR. Everyone I've seen who puts a >> number pad in a phone or softphone does something in audio when you hit one >> (generic beep or DTMF tone normally), so one would expect anyone building an >> app which expects to access PSTN gateways to include that. This makes it >> easier for them to not shoot themselves in the foot. It's not mandatory, >> but likely would be a source of frustration and odd hard-to-reproduce bugs >> and possibly works-in-one-browser but fails 1-in-20-times in another >> browser. > OK, I see where you are coming from. This is not how I imagined echo > cancellation being built in a browser. Relying entirely on feedback > loops within the browser is insufficient - you have to use the whole > of the audio that goes to the speaker. Sure, but the only way to do that for sure is to build it into the OS audio drivers. However you can't count on AEC being on or working perfectly in any case. Having the audio tones offset from the outgoing DTMF (and from the disabling of outgoing normal audio) or having the lengths not match open the possibility of a local-feedback tone getting sent. Users are often given direct control of the AEC by apps, for example, or the AEC may have mis-trained, or the user may be holding the mic and moving it around, etc. > For that reason, echo cancellation is a browser capability. I don't > necessarily want an application getting access to what music I'm > listening to. Well, that's a separate issue - if you give it access to the mic, it can turn off AEC and get whatever is playing out from the speakers. Agreed totally that you *want* all the browser audio to feed into the AEC. I'll note that the webrtc.org audio chains include the AEC at the last point they can within that stack. -- Randell Jesup randell-ietf@jesup.org
Received on Saturday, 11 August 2012 05:05:48 UTC