Closed
Bug 1023947
Opened 10 years ago
Closed 7 years ago
Serious echo in Mac-to-Mac calls with headset
Categories
(Core :: WebRTC: Audio/Video, defect, P1)
Tracking
()
RESOLVED
INCOMPLETE
mozilla34
backlog | webrtc/webaudio+ |
People
(Reporter: ekr, Assigned: jesup)
References
Details
Attachments
(3 files, 1 obsolete file)
3.30 KB,
patch
|
jesup
:
review+
|
Details | Diff | Splinter Review |
4.53 KB,
patch
|
kinetik
:
review+
|
Details | Diff | Splinter Review |
8.79 KB,
patch
|
jesup
:
review+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•10 years ago
|
||
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.
Updated•10 years ago
|
Assignee: nobody → paul
Comment 2•10 years ago
|
||
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.
Attachment #8458794 -
Flags: review?(rjesup)
Comment 3•10 years ago
|
||
This is needed for the next patch.
Attachment #8458796 -
Flags: review?(kinetik)
Comment 4•10 years ago
|
||
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.
Attachment #8458797 -
Flags: review?(rjesup)
Comment 5•10 years ago
|
||
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.
Attachment #8458796 -
Flags: review?(kinetik) → review+
Assignee | ||
Updated•10 years ago
|
Attachment #8458794 -
Flags: review?(rjesup) → review+
Assignee | ||
Updated•10 years ago
|
Attachment #8458797 -
Flags: review?(rjesup) → review+
Comment 6•10 years ago
|
||
Updated•10 years ago
|
Attachment #8459342 -
Attachment is obsolete: true
Comment 7•10 years ago
|
||
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
Flags: needinfo?(paul)
Comment 9•10 years ago
|
||
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)
Flags: needinfo?(paul)
https://hg.mozilla.org/mozilla-central/rev/da477d34528d
https://hg.mozilla.org/mozilla-central/rev/9d323d5bb542
https://hg.mozilla.org/mozilla-central/rev/e9e563d4f5b9
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
Comment 11•10 years ago
|
||
Paul: why did you comment out small-shot-mp3.mp4 in manifest.js in your patches in this bug?
Flags: needinfo?(paul)
Comment 12•10 years ago
|
||
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
Flags: needinfo?(paul)
Comment 13•10 years ago
|
||
Reporter | ||
Comment 14•10 years ago
|
||
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 16•10 years ago
|
||
(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
Assignee | ||
Comment 17•10 years ago
|
||
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
Flags: needinfo?(rjesup)
Reporter | ||
Comment 18•10 years ago
|
||
(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
Assignee | ||
Comment 19•10 years ago
|
||
(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.
Updated•9 years ago
|
Assignee: padenot → rjesup
backlog: --- → webRTC+
Rank: 10
Priority: -- → P1
Comment 21•9 years ago
|
||
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
Comment 22•9 years ago
|
||
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.
Reporter | ||
Comment 23•9 years ago
|
||
I also believe I get echo with Richard who is just using a Mac. Next time I will capture it.
Comment 24•7 years ago
|
||
2 year old logs are probably not useful to fix any recent issues.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 7 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•