Closed Bug 1674283 Opened 4 years ago Closed 4 years ago

Audio playback drops out when muting and unmuting your mic on Doxy.me calls using a Bluetooth headset

Categories

(Core :: WebRTC: Audio/Video, defect)

defect

Tracking

()

VERIFIED FIXED
85 Branch
Tracking Status
firefox84 --- verified
firefox85 --- verified

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
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

  1. Join a https://doxy.me/ call.
  2. While the other person is talking, click the Doxy UI's microphone button to mute your mic.
  3. 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.

Attached file about:support
Here is my about:support.
Component: Audio/Video → WebRTC

(In reply to Chris Peterson [:cpeterson] from comment #1)

Here is my about:support.

Chris, is this observed with a Bluetooth headset?

Flags: needinfo?(cpeterson)

Jan-Ivar, does this sound familiar to you? I am not sure how we could reproduce this if doxy.me is no longer working.

Flags: needinfo?(jib)

(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.

Flags: needinfo?(cpeterson)
Summary: Audio playback drops out when muting and unmuting your mic on Doxy.me calls → Audio playback drops out when muting and unmuting your mic on Doxy.me calls using a Bluetooth headset

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.

Component: WebRTC → WebRTC: Audio/Video
Flags: needinfo?(jib) → needinfo?(cpeterson)

(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. :)

Flags: needinfo?(cpeterson) → needinfo?(jib)

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?

Flags: needinfo?(jib) → needinfo?(cpeterson)

(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.

Flags: needinfo?(cpeterson) → needinfo?(jib)

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).

Flags: needinfo?(jib) → needinfo?(cpeterson)
Attached file log.txt.main.moz_log

(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)
Flags: needinfo?(cpeterson)

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.)

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.

Flags: needinfo?(cpeterson)

(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. :(

Flags: needinfo?(cpeterson)

Please attach logs, then :-).

Flags: needinfo?(cpeterson)

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.

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.

Flags: needinfo?(cpeterson) → needinfo?(padenot)

Here is the log from my child process: comment-15-build-log.txt.child-3.moz_log

Assignee: nobody → padenot
Status: NEW → ASSIGNED
Attachment #9187625 - Attachment is obsolete: true

Depends on D97024

Attachment #9188333 - Attachment is obsolete: true
Pushed by padenot@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ba1285f0cd47 Don't mute audio input devices when disabling the track. r=jib https://hg.mozilla.org/integration/autoland/rev/8c949ad30253 Backout part of bug 1624322. r=jib https://hg.mozilla.org/integration/autoland/rev/d0fe898225ac Add a missing track disabling in microphone processing code. r=pehrsons https://hg.mozilla.org/integration/autoland/rev/2a289cf72be3 When a mic is already off, don't attempt to turn it off. r=pehrsons https://hg.mozilla.org/integration/autoland/rev/3897000a5248 Test disabling an input track in gtest. r=pehrsons

Is this something we should consider for Beta uplift?

Flags: needinfo?(padenot) → in-testsuite+

(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).

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:
Attachment #9187711 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Comment on attachment 9187711 [details]
Bug 1674283 - Don't mute audio input devices when disabling the track. r?jib

Approved for 84.0b7.

Attachment #9187711 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

I verified (in 85.0a1) that this bug has indeed been fixed. 👍🏻

Status: RESOLVED → VERIFIED

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.

I verified on Beta version 84.0b8 that this bug has been fixed.

Flags: qe-verify+
Regressions: 1678352
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: