Adam and I just did a series of Mac-to-Mac calls. We are both wearing headsets (mine is a simple headphones with no microphone and I think Adam's is an Apple phone headset with built-in mic). I am hearing my own voice ~200-300ms reflected from his end. It's clear and about 1/2 the volume of Adam's voice. We just tried again with an instrumented build with patches by Jesup and it's fine with the instrumentation.

Update Adam and I just tried some additional testing. 1. Swapping regular headphones instead of headphones with mics on Adam's end removes the problem. 2. Swapping in headphones with a mic on my end creates the converse problem for him. 3. Adam and I just re-tried with Chrome on my end and I still see very serious echo from him but he does not from me. Which I think makes clear the problem is Firefox.

This won't live long (because MSG refactoring), but is useful: when you plug earbuds that have a mic, the callback is not going to get called for a little while. We detect that and drop the frame when Write()n.

This is needed for the next patch.

This is brutal but seem to work in my testing. Not sure why, though. We could also try to do the same on the input.

Comment on attachment 8458796 [details] [diff] [review] Allow getting the current input device in cubeb. r= Review of attachment 8458796 [details] [diff] [review]: ----------------------------------------------------------------- ::: media/libcubeb/include/cubeb.h @@ +131,5 @@ > > /** Output device description */ > typedef struct { > char * name; /**< The name of the output device */ > + char * in_name; /**< The name of the output device */ Make these output_name and input_name. ::: media/libcubeb/src/cubeb_audiounit.c @@ +829,1 @@ > int audiounit_stream_get_current_output_device(cubeb_stream * stm, Rename this and the public version to get_current_devices or something.

https://hg.mozilla.org/integration/mozilla-inbound/rev/274b2b25d167 https://hg.mozilla.org/integration/mozilla-inbound/rev/c0045bb1849e https://hg.mozilla.org/integration/mozilla-inbound/rev/b6bb38846333

I backed these out (along with the changes from bug 1027713) in https://hg.mozilla.org/integration/mozilla-inbound/rev/5dc0231d0153 for making cppunit tests frequently fail like this: https://tbpl.mozilla.org/php/getParsedLog.php?id=44534511&tree=Mozilla-Inbound

https://hg.mozilla.org/integration/mozilla-inbound/rev/da477d34528d https://hg.mozilla.org/integration/mozilla-inbound/rev/9d323d5bb542 https://hg.mozilla.org/integration/mozilla-inbound/rev/e9e563d4f5b9 (the issue was fixed by 1045018, pushed at the same time)

https://hg.mozilla.org/mozilla-central/rev/da477d34528d https://hg.mozilla.org/mozilla-central/rev/9d323d5bb542 https://hg.mozilla.org/mozilla-central/rev/e9e563d4f5b9

Paul: why did you comment out small-shot-mp3.mp4 in manifest.js in your patches in this bug?

wow, sorry, I probably did that because at some point I had a problem with gstreamer (I think I broke my local install somehow) that made content/media mochitests time out locally. I backed it out in https://hg.mozilla.org/integration/mozilla-inbound/rev/27d7fcc8c8a5

Randell, I just had a call with Richard (CC'ed) which showed extremely bad echo in exactly this scenario. I am on Aurora 34.0a2 (2014-10-13) and he is on Nightly 36.0a1 (2014-10-15). As before, Richard had a headset with a microphone and I heard very bad echo of mine from his end both before and after he plugged in the headset. We are both on 13" rMBPs. I have Mavericks and I assume so does Richard.

Needinfo Jesup for next steps.

(In reply to Eric Rescorla (:ekr) from comment #14) > Randell, > > I just had a call with Richard (CC'ed) which showed extremely bad echo > in exactly this scenario. I am on Aurora 34.0a2 (2014-10-13) and he > is on Nightly 36.0a1 (2014-10-15). As before, Richard had a headset > with a microphone and I heard very bad echo of mine from his end both > before and after he plugged in the headset. > > We are both on 13" rMBPs. I have Mavericks and I assume so does Richard. I just had another Loop call with this problem. I heard echo; far end did not. * both MBPs * both using headset with microphone * My end: Nightly 36.0a1 (2014-10-16) * Far end: Firefox 32.02

Ok: a few issues First, we seem to have lost one of the Mac audio fixes (this one) in padenot's bug 848954 refactor of MSG. This is being worked at a high priority in bug 1085356. The other primary fix for mac audio (panning to right speaker on macbookpro's) seems to work on my 2011 mbp; we'll test that more though. However: bug 848954 landed late in 34 (now beta), not on 32 or 33. Nor is the fix here or the panning fix in 32 or 33 - they landed early in 34. So echo on a call with a macbookpro in 32 is to be expected unless a good headset is used and plugged in before the call; doubly so if they use speakerphone mode. With mac headsets if you change the audio device after the audio channel has been opened we end up with circa 1 second delay, which is what this bug is meant to address; many people plug in the earbuds after audio has been opened out of habit; it may also be triggered by other earlier use of audio in the browser. In the future, if/when something like this is seen in versions that should work, here are some debug instructions: Make another call, with you on headset (before the call), him not. Verify there is echo or not, at a reasonable volume (max volume on mac's generally distorts badly and cancellation becomes rough). At the far end (where the echo is coming from, which you are hearing at the near end), go to about:webrtc and select Start AEC logs (bottom of page). talk normally back and forth for 30 seconds, then Stop AEC logs. Then plug in the headset, and verify if the echo is still there (and if there is any change in echo time period - the OS problem we worked around was that after plugging in, the OS causes a ~1-second delayed echo, which we fixed by closing and reopening the output device ('speakers')). Then repeat the AEC logging sequence. You can then end the call, and forward the logs which should all be in /tmp

(In reply to Randell Jesup [:jesup] from comment #17) > Ok: a few issues > > First, we seem to have lost one of the Mac audio fixes (this one) in > padenot's bug 848954 refactor of MSG. This is being worked at a high > priority in bug 1085356. The other primary fix for mac audio (panning to > right speaker on macbookpro's) seems to work on my 2011 mbp; we'll test that > more though. > > However: bug 848954 landed late in 34 (now beta), not on 32 or 33. Nor is > the fix here or the panning fix in 32 or 33 - they landed early in 34. So > echo on a call with a macbookpro in 32 is to be expected unless a good > headset is used and plugged in before the call; doubly so if they use > speakerphone mode. As noted in c16, this was with 34 and 36. > Make another call, with you on headset (before the call), him not. Verify > there is echo or not, at a reasonable volume (max volume on mac's generally > distorts badly and cancellation becomes rough). At the far end (where the > echo is coming from, which you are hearing at the near end), go to > about:webrtc and select Start AEC logs (bottom of page). talk normally back > and forth for 30 seconds, then Stop AEC logs. Then plug in the headset, and > verify if the echo is still there (and if there is any change in echo time > period - the OS problem we worked around was that after plugging in, the OS > causes a ~1-second delayed echo, which we fixed by closing and reopening the > output device ('speakers')). Then repeat the AEC logging sequence. You can > then end the call, and forward the logs which should all be in /tmp

(In reply to Eric Rescorla (:ekr) from comment #18) > (In reply to Randell Jesup [:jesup] from comment #17) > > Ok: a few issues > > > > First, we seem to have lost one of the Mac audio fixes (this one) in > > padenot's bug 848954 refactor of MSG. This is being worked at a high > > priority in bug 1085356. The other primary fix for mac audio (panning to > > right speaker on macbookpro's) seems to work on my 2011 mbp; we'll test that > > more though. > > > > However: bug 848954 landed late in 34 (now beta), not on 32 or 33. Nor is > > the fix here or the panning fix in 32 or 33 - they landed early in 34. So > > echo on a call with a macbookpro in 32 is to be expected unless a good > > headset is used and plugged in before the call; doubly so if they use > > speakerphone mode. > > As noted in c16, this was with 34 and 36. Likely the issue you had (34 & 36) was the first paragraph above. Richard reported a problem with echo generated by a user on 32, which led to the discussion in the 2nd paragraph. I hope to have a patch today from padenot to re-instate this; due to removing buffers the patch has to change from the old one. Also, pan-to-right is functioning on my 2013 MBP as well.

Since my system seems to be the one generating echo in these calls (which EKR and I can reproduce fairly easily), here's an AEC log from my end that demonstrates the issue. My system is running 42.0b8, https://www.dropbox.com/s/hpwxb5jjt97odmj/aec-2015-10-22.tgz?dl=0

Thanks, Adam. I'm going to look at this now and circle in Randell. To add more info about the calling set up: Adam has an external USB soundcard that he uses for the majority of his audio. It is usually his default device. When he uses Hello, he has to tweak his default device, since there’s no way to switch it in Firefox currently. FYI: I am prioritizing the platform bug to allow changing the audio and video output for a call. In fact, I'm prioritizing that and changing the input and output for a call on-the-fly this quarter to coincide with the full duplex changes that are coming.

I also believe I get echo with Richard who is just using a Mac. Next time I will capture it.

2 year old logs are probably not useful to fix any recent issues.