Audio playback drops out when muting and unmuting your mic on Doxy.me calls using a Bluetooth headset
Categories
(Core :: WebRTC: Audio/Video, defect)
Tracking
()
People
(Reporter: cpeterson, Assigned: padenot)
References
()
Details
Attachments
(10 files, 2 obsolete files)
36.92 KB,
text/plain
|
Details | |
173.81 KB,
text/plain
|
Details | |
28.00 KB,
text/plain
|
Details | |
172.99 KB,
text/plain
|
Details | |
28.42 KB,
text/plain
|
Details | |
47 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
|
Details | Review |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
Steps to reproduce
- Join a https://doxy.me/ call.
- While the other person is talking, click the Doxy UI's microphone button to mute your mic.
- After a couple seconds, click the Doxy UI's microphone button to unmute your mic.
Expected result
You should be able to hear the other person's audio seamlessly while you mute and unmute your own mic.
Actual result
When you mute your mic, the other person's audio drop outs for about 100-200 ms. When you unmute your mic, the other person's audio drops out for about 500-1000 ms.
In this case, the other person is using Chrome (on macOS), but I don't know if that matters for this audio dropout issue.
This is a not (recent) regression. I was able to reproduce this bug before Doxy.me calls broke in Firefox a couple months ago (bug 1668313), but I didn't file a bug at that time.
Reporter | ||
Comment 1•4 years ago
|
||
Comment 2•4 years ago
|
||
(In reply to Chris Peterson [:cpeterson] from comment #1)
Here is my about:support.
Chris, is this observed with a Bluetooth headset?
Comment 3•4 years ago
|
||
Jan-Ivar, does this sound familiar to you? I am not sure how we could reproduce this if doxy.me is no longer working.
Reporter | ||
Comment 4•4 years ago
|
||
(In reply to Nico Grunbaum [:ng, @chew:mozilla.org] from comment #2)
Chris, is this observed with a Bluetooth headset?
Yes. I'm using a Bluetooth headset.
I just tried testing my laptop's built-in mic and speakers instead of my Bluetooth headset. The audio playback did NOT drop out. So this problem seems specific to my Bluetooth headset and Firefox. (doxy.me doesn't have this problem when using Chrome and my Bluetooth headset.)
Also, I have the "WebRTC Global Mute Toggles" experimental feature enabled in about:preferences#experimental. I hear the same audio playback dropouts when muting using the WebRTC Global Mute's floating toolbar as when I click doxy.me's mute button in content.
(In reply to Nico Grunbaum [:ng, @chew:mozilla.org] from comment #3)
Jan-Ivar, does this sound familiar to you? I am not sure how we could reproduce this if doxy.me is no longer working.
Note that doxy.me works in Nightly again since the site was added to the RTX blocklist in bug 1668313.
Comment 5•4 years ago
|
||
Hi Chris, thanks for filing. Does this repro just on doxy, or other sites like google meet and whereby as well? Does it repro here?
Sounds like something we (thought we) fixed with bug 1624322: We used to relinquish/reaquire the microphone hardware on mute/unmute as we do for camera, but this caused mic-ed BT headsets to reinitialize, resetting BT speakers in the process causing a 200ms speaker drop. So bug 1624322 added a workaround to not stop microphone hardware IF speakers on the same device (same groupId
as observed in enumerateDevices) are in use.
Reporter | ||
Comment 6•4 years ago
|
||
(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #5)
Hi Chris, thanks for filing. Does this repro just on doxy, or other sites like google meet and whereby as well? Does it repro here?
I haven't tested Google Meet or Whereby, but I can, if you like.
I tried your jsfiddle test case and I can't reproduce the audio dropouts. I hear continuous audio playing as I toggle the "mute" checkbox.
Sounds like something we (thought we) fixed with bug 1624322: We used to relinquish/reaquire the microphone hardware on mute/unmute as we do for camera, but this caused mic-ed BT headsets to reinitialize, resetting BT speakers in the process causing a 200ms speaker drop. So bug 1624322 added a workaround to not stop microphone hardware IF speakers on the same device (same
groupId
as observed in enumerateDevices) are in use.
If you have a test case you'd like me to bisect using mozregression, just let me know. Bisecting using doxy.me calls is probably not practical, unless there's a way to create calls without involving a health care professional. :)
Comment 7•4 years ago
|
||
I tried your jsfiddle test case and I can't reproduce the audio dropouts. I hear continuous audio playing as I toggle the "mute" checkbox.
Does it repro here?
Reporter | ||
Comment 8•4 years ago
|
||
(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #7)
I tried your jsfiddle test case and I can't reproduce the audio dropouts. I hear continuous audio playing as I toggle the "mute" checkbox.
Does it repro here?
Fx84 Nightly with Bluetooth headset = repro dropouts
Fx82 Release with Bluetooth headset = repro dropouts
Fx82 Release with laptop's built-in mic and speaker = NO repro
Chrome 86 with Bluetooth headset = NO repro
Note to anyone else trying to repro the problem using the jsfiddle test: you need to click jsfiddle's "Run" button before the test's sound will play.
Assignee | ||
Comment 9•4 years ago
|
||
Chris, can you please repro with those logging modules at those logging levels:
MediaManager:4,cubeb:5,sync,timestamp
Can you also please confirm you're using this Bose headset for both audio input and output, or if you're using the output of the headset and the built-in input from the laptop, or another combination ?
Bluetooth audio on Windows is a bit finicky, it's not partularly hard to fix, but I might need a thing or two about this headset (strings the driver reports).
Reporter | ||
Comment 10•4 years ago
•
|
||
(In reply to Paul Adenot (:padenot) from comment #9)
Chris, can you please repro with those logging modules at those logging levels:
MediaManager:4,cubeb:5,sync,timestamp
Here is my log file for my parent process: log.txt.main.moz_log
Can you also please confirm you're using this Bose headset for both audio input and output, or if you're using the output of the headset and the built-in input from the laptop, or another combination ?
When I'm using my Bose headset for audio output, I can reproduce this bug whether I'm using the Bose headset for audio input or my laptop's built-in mic (Realtek(R) Audio
):
Input \ Output | Built-in speaker | Bose Headset |
---|---|---|
Built-in mic | No repro | Repro |
Bose headset | (I don't know how to test this configuration.) | Repro |
Bluetooth audio on Windows is a bit finicky, it's not partularly hard to fix, but I might need a thing or two about this headset (strings the driver reports).
I have a Bose QuietComfort 35 Series II with firmware version 4.5.2 (according to my Bose Connect app).
Note that my headset shows up twice in Windows' list of audio devices. For example, here the list of available audio devices in Vidyo:
- Select a Microphone:
Headset (Chris's Bose QC35 II Hands-Free AG Audio)
Microphone (Realtek(R) Audio)
- Select a Speaker:
Headphones (2- Chris's Bose QC35 II Stereo)
Speakers/Headphones (Realtek(R) Audio)
Headset (Chris's Bose QC35 II Hands-Free AG Audio)
Reporter | ||
Comment 11•4 years ago
|
||
Here is my log file for the child process: log.txt.child-3.moz_log
(There were other child process log files, but this is the only log file with any output.)
Assignee | ||
Comment 12•4 years ago
|
||
Chris, thanks for the logs, here is a build with a fix: https://treeherder.mozilla.org/jobs?repo=try&revision=a69c09175dd9b792fee7a702c5336f5e3d98afb6, if you want to check. I can't be 100% sure, because I don't have this headset, but it's likely.
Should be in nightly in a couple days.
Reporter | ||
Comment 13•4 years ago
|
||
(In reply to Paul Adenot (:padenot) from comment #12)
Chris, thanks for the logs, here is a build with a fix: https://treeherder.mozilla.org/jobs?repo=try&revision=a69c09175dd9b792fee7a702c5336f5e3d98afb6, if you want to check. I can't be 100% sure, because I don't have this headset, but it's likely.
Unfortunately, I can still repro the audio dropouts with this Try build. :(
Assignee | ||
Comment 15•4 years ago
|
||
Hrm no I think I understand what's up now, and the difference with my setup. I haven't found this because my Windows machine happens to have the Hands Free side of the bluetooth device as the default audio output device, and you have a more sensible setup, with the A2DP side of this device being the default device, and the Hands Free side as the default communication device.
A new build: https://treeherder.mozilla.org/jobs?repo=try&revision=4070576ea3f233ce8e19e299948d3dc7bffff8c3, with fprintf(stderr, ...);
to make it clear what is happening.
Reporter | ||
Comment 16•4 years ago
|
||
A new build: https://treeherder.mozilla.org/jobs?repo=try&revision=4070576ea3f233ce8e19e299948d3dc7bffff8c3, with
fprintf(stderr, ...);
to make it clear what is happening.
I can still reproduce the audio dropouts. Here is the log from my main process: comment-15-build-log.txt.moz_log.
Will the fprintfs to stderror show up in my Windows command prompt or in the moz_log files? I didn't see any messages in my Windows prompt when I ran firefox.exe.
Reporter | ||
Comment 17•4 years ago
|
||
Here is the log from my child process: comment-15-build-log.txt.child-3.moz_log
Assignee | ||
Comment 18•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 19•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 20•4 years ago
|
||
Depends on D97024
Assignee | ||
Comment 21•4 years ago
|
||
Depends on D97202
Assignee | ||
Comment 22•4 years ago
|
||
Depends on D97332
Assignee | ||
Comment 23•4 years ago
|
||
Depends on D97333
Assignee | ||
Comment 24•4 years ago
|
||
Depends on D97333
Updated•4 years ago
|
Comment 25•4 years ago
|
||
Comment 26•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/ba1285f0cd47
https://hg.mozilla.org/mozilla-central/rev/8c949ad30253
https://hg.mozilla.org/mozilla-central/rev/d0fe898225ac
https://hg.mozilla.org/mozilla-central/rev/2a289cf72be3
https://hg.mozilla.org/mozilla-central/rev/3897000a5248
Comment 27•4 years ago
|
||
Is this something we should consider for Beta uplift?
Assignee | ||
Comment 28•4 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #27)
Is this something we should consider for Beta uplift?
A simple pref flip (the first patch in this series) will suffice if we want this for beta, the rest is to make the behaviour more consistent if a Nightly Experiment is enabled (WebRTC Global Mute toggle
).
Assignee | ||
Comment 29•4 years ago
|
||
Comment on attachment 9187711 [details]
Bug 1674283 - Don't mute audio input devices when disabling the track. r?jib
Beta/Release Uplift Approval Request
- User impact if declined: When muting the mic and using a bluetooth device, a glitch in the output can be heard. Possibly, increased latency between input and output can be observed, reducing the overall quality of the call.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: Use any WebRTC service with a bluetooth device. Muting the microphone should not cause any perturbation in the output, in terms of quality or brief pause.
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): It's a pref flip, and the new behaviour was already exercised in some cases (but not all).
- String changes made/needed:
Assignee | ||
Updated•4 years ago
|
Comment 30•4 years ago
|
||
Comment on attachment 9187711 [details]
Bug 1674283 - Don't mute audio input devices when disabling the track. r?jib
Approved for 84.0b7.
Comment 31•4 years ago
|
||
bugherder uplift |
Updated•4 years ago
|
Reporter | ||
Comment 32•4 years ago
|
||
I verified (in 85.0a1) that this bug has indeed been fixed. 👍🏻
Assignee | ||
Comment 33•4 years ago
|
||
Many thanks for confirming Chris. We did take the longer but more thorough approach (there are different kind of muting at play here), but it should also be fixed in 84 just via the pref flip.
Comment 34•4 years ago
|
||
I verified on Beta version 84.0b8 that this bug has been fixed.
Description
•