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

Status: VERIFIED FIXED

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

Description

[Daniel Bodea [:danibodea]]

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.

Comment 1

[Daniel Bodea [:danibodea]]

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.

Comment 2

[Jan-Ivar Bruaroey [:jib] (needinfo? 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?

Comment 3

[Alex Chronopoulos [:achronop]]

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

Comment 4

[Alex Chronopoulos [:achronop]]

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.

Comment 5

[Jens Stutte [:jstutte]]

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

Comment 6

[Steve Fink [:sfink] [:s:]]

I just noticed the same behavior yesterday in Nightly 20200327094805 on Fedora 31 while watching https://www.amazon.com/gp/video/detail/B01MSZILS5/ref=atv_dl_rdr?autoplay=1

I have a USB headset and a speaker plugged into the headphone audio port. I used pavucontrol to set the audio output to the headphone jack, then paused and resumed, and it switched the output back to the USB headset. This seems to be new behavior for me (so it's possible that this is a different issue?)

Comment 7

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

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.

Comment 8

[Alex Chronopoulos [:achronop]]

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.

Comment 9

[Steve Fink [:sfink] [:s:]]

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

Comment 10

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

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

Comment 11

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

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

Comment 12

[Paul Adenot (:padenot)]

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

Comment 13

[Alex Chronopoulos [:achronop]]

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

Comment 14

[Alex Chronopoulos [:achronop]]

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

Comment 15

[Alex Chronopoulos [:achronop]]

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.

Comment 16

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

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.

Comment 17

[Alex Chronopoulos [:achronop]]

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

Comment 18

[Alex Chronopoulos [:achronop]]

Attachment: Bug 1628634 - Update cubeb-pulse-rs. r?padenot

Comment 19

[Alex Chronopoulos [:achronop]]

Attachment: Bug 1628634 - mach vendor rust. r?padenot

Depends on D71929

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9b5ba030372a
Update cubeb-pulse-rs. r=padenot
https://hg.mozilla.org/integration/autoland/rev/2203d818a3b4
mach vendor rust. r=padenot

Comment 21

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/9b5ba030372a
https://hg.mozilla.org/mozilla-central/rev/2203d818a3b4

Comment 22

[Daniel Bodea [:danibodea]]

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