Closed Bug 1628634 Opened 2 years ago Closed 2 years ago

[wfh] The input source is switched after muting and un-muting the sound

Categories

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

Desktop
Linux
defect

Tracking

()

VERIFIED FIXED
mozilla77
Tracking Status
firefox-esr68 --- wontfix
firefox74 --- wontfix
firefox75 --- wontfix
firefox76 --- wontfix
firefox77 --- verified

People

(Reporter: danibodea, Assigned: achronop)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [wfh])

Attachments

(2 files)

Note

  • When the user mutes the test case app and unmutes it again, the input source (mic) will be switched from external to integrated.

Affected versions

  • all latest versions of the 4 main channels

Affected platforms

  • Ubuntu 18

Steps to reproduce

  1. USB headphones ready to use, but not inserted in the laptop.
  2. Load test case: https://jsfiddle.net/jib1/n7bmkjnf.
  3. Permit the integrated microphone.
  4. Connect the USB headphones.
    Notice: The input and output are being switched to the headphones.
  5. Mute and unmute the sound, from the checkbox in the fiddle's bottom-right section.

Expected result

  • The input source is still from the headphones mic.

Actual result

  • The input source is switched back to the integrated mic.

Additional notes

  • Could not reproduce on Windows 10, on the same laptop.
  • It WAS reproduced on another laptop with Ubuntu 18.
  • For SV team: this was reproduced on Laptop595.
Summary: The input source is switched because after muting and un-muting the sound → The input source is switched after muting and un-muting the sound
Summary: The input source is switched after muting and un-muting the sound → [wfh] The input source is switched after muting and un-muting the sound
Whiteboard: [wfh]

I attempted providing a regression range, but I was unable to finish it due to missing builds.
These are my results:
39:43.77 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1a0c506d69a80ee792d73b4090eeb5e755f17bf8&tochange=c4c1a90df788b7634da5a89f417bf55198172640
41:22.34 INFO: There are no build artifacts on inbound for these changesets (they are probably too old).

I thought that mozregression might be out of date, updated it and retried. I got another regression range:
20:03.34 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c4c1a90df788b7634da5a89f417bf55198172640&tochange=37b33c4f58b9372ad8d4fa969ad7a86ae305790a

I think this is the best I can do. If you do want me to reattempt it, please NI me.

Wow that's an old regression.

This looks like a shortcoming of mitigations added way back for lack of headset detection.

Notice: The input and output are being switched to the headphones.

As I mention in bug 1628689 comment 2, we shouldn't be doing this in the first place, which may explain why the mitigation turns into a pumpkin after mute/unmute.

Paul, thoughts? As I mention in the other bug maybe we should enable "audiooutput" enumeration to facilitate headset detection, even if setSinkId is not ready?

Flags: needinfo?(padenot)
Regressed by: 1404977
See Also: → 1628689
Has Regression Range: --- → yes

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #2)

As I mention in bug 1628689 comment 2, we shouldn't be doing this in the first place, which may explain why the mitigation turns into a pumpkin after mute/unmute.

Oh, this is the use case that I have asked for in Bug 1628689#c3. As I said we can do it if we want to.

Flags: needinfo?(padenot)

Regarding the reported error, I cannot reproduce. I have tried the latest Nightly and Release. I am on fedora. Have you tried it on Nightly.

Flags: needinfo?(daniel.bodea)

Hi Jan-Ivar, can you please (let) triage this bug? Thank you!

Flags: needinfo?(jib)

The fact that muting and unmuting changes source is clearly a bug from a user's perspective that I think we should remedy asap.

From my view, I see two ways to fix this (assuming my theory in comment 2 is correct):

  1. Improve our non-spec headset-magic mitigation, to survive mute/unmute (dig down further)
  2. Remove our non-spec headset-magic mitigation (dig up) and fix bug 1630289 instead to fix real WebRTC sites (not jsfiddle)
    1. Note: this won't fix jsfiddle in comment 0 since Notice: The input and output are being switched to the headphones. in step 4 is a spec violation, since it is up sites not browsers to do these switches (see bug 1630289).

But I think Paul and/or Alex need to weigh in on whether this makes sense, since they're the experts on our implementation here. Another wrinkle is some OSes (macOS) appears to do some headset magic of their own, so I don't know how that fits in to all this.

Flags: needinfo?(jib) → needinfo?(padenot)
Priority: -- → P2

Looking at the description again the problem is in step 4 that the input changes when the new input (the one in the headset) is plugged in.

(In reply to Alex Chronopoulos [:achronop] from comment #8)

Looking at the description again the problem is in step 4 that the input changes when the new input (the one in the headset) is plugged in.

That's not how I read the original report. Step 4 comments that the input source switches to the headphones, and the expected result is that the input source stays with the headphones. But instead it switches back to the mic, apparently while muting and unmuting as given in the bug title.

But this makes me realize that my bug is different; I'm talking about outputs, not inputs.

Step 4 comments that the input source switches to the headphones, and the expected result is that the input source stays with the headphones.

Can you show me spec support that says browsers should automatically switch an existing input source to headphones in the first place?

The gUM spec says: "Once selected, the source of the MediaStreamTrack MUST NOT change."

Even Chrome with its smart "Default" device respects this (I'm on mac):

Microphone (live): Default - MacBook Pro Microphone (Built-in)

That is: if I activate my airpods after starting that jsfiddle, the input source stays the same (laptop mic). I have to refresh the page to switch it:

Microphone (live): Default - JIB’s AirPods (Bluetooth)

Firefox doesn't even have this special device, so this is even more true in our model (the fiddle works the same way in Firefox).

So if linux works differently from comment 10 then that's the bug imho.

We've analyzed with alex yesterday that the way pulseaudio is configured on ubuntu by default auto-switches.

Flags: needinfo?(padenot)

Yeah, Ubuntu has an extra configuration for hot-plugin. We can disable moving to the default device in cubeb level. I'll create patch.

Jan-Ivar, do you have an opinion about whether we need to disable moving for both input and output, or just input?

Flags: needinfo?(jib)

I take back the question to Jan-Ivar. We need the output to switch to the default device for playback also. When setSinkId is in place we can consider it again.

Flags: needinfo?(jib)

Yeah these are separate questions I think. For one, the audio output spec has a clear concept of OS default in the API, and the notion that it may change. E.g. a user "is using a laptop with system audio directed to a USB headset".

Disclaimer on the mic question: I don't have a linux box. If someone who does could check how Chrome works on linux (ubuntu and/or other flavors) with the fiddle in comment 10 that would be great. If there's a strong OS pattern here perhaps it outweighs cross-platform web compat.

The fix for this one has landed upstream in https://github.com/djg/cubeb-pulse-rs/pull/54

Assignee: nobody → achronop
Status: NEW → ASSIGNED

Depends on D71929

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla77

I can confirm the verification of this fix. Thank you.

Status: RESOLVED → VERIFIED
Flags: needinfo?(daniel.bodea)
You need to log in before you can comment on or make changes to this bug.