User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.93 Safari/537.36 Steps to reproduce: Start a call on apprtc with another person on the end. This also happens when making a call using gittogether.com. Actual results: We frequently hear high-pitched feedback. The attached recording has multiple instances of the feedback, the first of which occurs at approximately 4 seconds. We've noticed that it seems to happen more when there is background noise, typing on the keyboard, and the fans are spinning. Expected results: Audio should not have feedback. This issue was also filed with webrtc.org https://code.google.com/p/webrtc/issues/detail?id=1716 which was merged into https://code.google.com/p/webrtc/issues/detail?id=827. The summary is this happens consistently with opus/48000 and is much harder to reproduce with isac/16000.

Tim, Randell, Can you take a look?

Judging by <https://code.google.com/p/webrtc/issues/detail?id=827#c36>, this is likely an issue with the echo canceller itself when running at SWB+ sampling rates. CC'ing jmspeex, who might have some idea what the issue is. Since we currently capture at 16 kHz, we don't actually need to run the AEC at SWB, and I'm not really sure why we would be, but I can look closer.

Looking at the file, the feedback occurs in the 5-6 kHz range, which is within the WB range. This doesn't necessarily mean that it's not a SWB issue, but at this point it's not what I'd suspect. Also, I'm a bit puzzled by the sampling rate (44.1 kHz) of the file and the fact that it's stereo (left and right are close, but not identical). Is that what the AEC is running on? Also, what AEC is this? The mobile one (no adaptive filter) or the "regular one"? This sort of feedback basically means that the loop gain (going through both speaker/mic pairs) is higher than unity at that frequency. I'd need more info to be able to say more.

Sorry, that file was actually from chrome. I'll redo this and generate a file from firefox. This is not the mobile AEC, it's the "regular one". This was recorded on a Macbook Pro where the inut sampling rate (of the hardware) was set to 44.1KHz. The same thing happens when it's set to 48KHz. If there is any other info I can get to help debug this, please let me know and I'll work on it.

So this effect is a common issue with echo cancelling, known as "howling". As I said earlier, that's caused by the audio getting amplified (gain>1) after going through the entire loop between the two users. Normally, the AEC is supposed to be able to cancel that, but sometimes echo leaks through at some frequency. In some cases, this is made worse by incorrect mixer settings, so this may be worth checking. For example, I've seen cases where the mic signal was fed directly into the speakers, so there's a feedback loop without even involving the remote user. I've also seen cases where the mic signal includes part of what's being sent to the speakers (directly from the mixers), which also adds echo. In some cases, it can also be insane audio setups, like having the mic really close to the speakers. Outside of this, I think it becomes a matter of AEC performance. In that case, the GIPS folks are the ones who know the actual algorithm.

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:22.0) Gecko/20100101 Firefox/22.0 I am unable to reproduce the issue using Firefox 22 beta 6 (buildID: 20130617145905). Called userB from a Mac OS X 10.6.8 machine to a Windows 8 x32 machine. Used headphones to make this call (we have no speakers). No background noise detected during the call.

This kind of thing is generally a problem when you have speakers, so this isn't really dispositive. Can you get some speakers and re-test?

Vline reports that Chrome 29 appears to fix this bug. We are currently on version 3.30 of the webrtc.org code. Google confirmed that they are using version 3.34. Unless there's a reason not to upgrade (Randell and I can't think of any), we'd like to upgrade to version 3.34 shortly after Firefox 26 becomes Nightly (i.e. within the next 2 weeks). We should then re-test this bug and see if it gets better or goes away.

Marking this as dependent on the 3.34 upgrade bug (bug 901583). Once the upgrade has landed, I'd love for someone (Adam?) to retest this to see how much upgrading to v3.34 helped. Thanks.

Adam: do you still see this in 26 (Aurora) which uses upstream 3.34? Also, recently a tail-length increase and change in the delay calculations landed upstream; this should be in the next import to Mozilla (for 28) from stable branch 3.43.

Randell: I just tried it on both Aurora and Nightly and both have the same result as before. The feedback is very bad (without headphones). We were testing this on gittogether.com making a local network (non-relay) call. We were in different rooms so there was no other audio path except through webrtc.

Ok, thanks. We know that currently the delay estimates for the AEC are sufficiently far off that AEC is unreliable (or more to the point, unreliable on some machines, and never works on others). Several fixes are in the works for this: moving the AEC to getUserMedia(), and landing an upstream update (in FF 28 likely) to increase the AEC tail length by 3x. I may try landing uplifting the AEC patch since it seems to be going well upstream.

Hi Adam - Can you retest? We uplifted the AEC patch long ago and have made more updates to audio since then. Thanks