Prerequisites

• Have a USB headset.

Affected versions

• 76.0b2
• 77.0a1(2020-04-08)
• 75.0

Affected platforms

• Windows 10 x64 (laptop)

Steps to reproduce

1. Join a call on https://opentokrtc.com/ without having the USB headset plugged in.
2. Allow Firefox to use the default microphone and webcam.
3. Plug in the USB headset.

Expected result

• Input source should change from the default one to the USB headset one.

Actual Result

• The used input source remains the built in one and not the one from the USB headset.

Regression range

• Will provide one ASAP.

Additional notes

• This issue also occurs on https://www.freeconferencecall.com/

I have tried to look for a regression for this issue but unfortunately this doesn't seem like a recent regression and the mozregression tool doesn't go further than 56 were I was able to reproduce the issue. Also I manually downloaded fx 48 and 50 and the browser didn't open the page https://opentokrtc.com/.

This is generally a site decision, not a browser decision. Sites that want this behavior are expected to

1. listen for the devicechange event
2. then call enumerateDevices()
3. then detect headset (groupId shared by both a "audioinput" and a "audioinput" device in that list.)
4. if detected, call getUserMedia({audio: {deviceId}}) to switch mic, and maybe also element.setSinkId(deviceId) to switch to headset speakers.

Unfortunately, enumeration of "audiooutput" devices is behind a pref in Firefox, blocking on the completion of setSinkId. Perhaps that's a mistake?

Afaik Firefox may have had some mitigations here in the past on some platforms (automatic switching), but I'm not updated on the latest status. Alex may know more, and be able to add the right blocking links.

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

Unfortunately, enumeration of "audioinput" devices is behind a pref in Firefox, blocking on the completion of setSinkId. Perhaps that's a mistake?

Probably you mean audiooutput here. If it is useful for some reason we can enable it without checking the pref. It's not too much work. What user case do you think it would benefit? The audiooutput cannot currently be used in our API.

Regarding the source, I agree with Jan-Ivar, it's up to the applications to detect the device change event and act on it if they want to.

I am closing this one. We can continue discussing the audiooutput case in Bug 1628634.

Probably you mean audiooutput here.

Yes, sorry I mis-typed. I've edited comment 2 to avoid confusing future readers.

I think it's better to keep this separate from bug 1628634 since they're different symptoms:

• To me, this issue is about our lack of supporting headset detection in JS (remedied by enabling enumeration of "audiooutput" devices)
• whereas bug 1628634 is about the shortcoming of our current (non-spec) mitigation (bursts on mute/unmute)

I'm going to reopen this and block it on a new bug to track enabling "audiooutput".

Jan-Ivar, I've marked this and Bug 1630289 as P2, feel free to change!

This issue is still reproducible in Firefox 78.0a1 (2020-05-05). Updating flags accordingly.

This issue is still reproducible in Firefox 79.0, 80.0, 81.0b2, 82.0a1 (2020-08-26), 81.0b on windows 10 64bit using talky.io as website. Updating flags accordingly.

I've added an improvised keyword to the summary to find it easier when the issue arises in our test runs again.
Also, this is not specific to Windows 10, nor to laptops, but on both laptop and desktop, Windows 10, Ubuntu 20 and Mac OS 11.

Also, this issue does not occur on Chrome.
The difference between the behavior seen in chrome and firefox is that Chrome instantly changes the input source back to the USB Headset when plugged in (even before confirming the "New audio device detected, Microphone, 'Use' button" Jitsi pop-up).

My steps with meet.jit.si web-app (new profile):

1. start call with USB Headset connected.
2. alow the permission door-hanger for USB headset and camera
3. unplug the USB headset
4. allow the permission door-hanger for the webcam microphone
   Observe: The microphone input switches to the webcam microphone.
5. reconnect the USB microphone
   Observe: Jitsi show a pop-up: "New audio device detected, Microphone, 'Use' button".
6. Click the "Use" button.

Result:

• The mic input does not switch to USB headset

• An error is displayed in the Jitsi: "Failed to access your microphone"
  (Details: Cannot use microphone for an unknown reason. Concurrent mic process limit."

• Browser Console messages shown after the click on "Use":

  2021-08-11T12:32:17.646Z [features/base/devices] set audio input device: HiA8S3R4em0/OMKMSUESsLjo/INEyy7xcerFJipeeq4= Logger.js:154:22
  2021-08-11T12:32:17.666Z [modules/RTC/RTCUtils.js] <obtainAudioAndVideoPermissions/r<>: Got media constraints: {"video":false,"audio":{"autoGainControl":true,"deviceId":"HiA8S3R4em0/OMKMSUESsLjo/INEyy7xcerFJipeeq4=","echoCancellation":true,"noiseSuppression":true}} Logger.js:154:22
  2021-08-11T12:32:17.902Z [modules/RTC/RTCUtils.js] <_getUserMedia/</<>: Failed to get access to local media. NotReadableError: Concurrent mic process limit. {"video":false,"audio":{"autoGainControl":true,"deviceId":"HiA8S3R4em0/OMKMSUESsLjo/INEyy7xcerFJipeeq4=","echoCancellation":true,"noiseSuppression":true}} Logger.js:154:22
  2021-08-11T12:32:17.906Z [features/base/tracks] <g/</<>: Failed to create local tracks
  Array [ "audio" ]
  DOMException: Concurrent mic process limit. Logger.js:154:22
  2021-08-11T12:32:18.301Z [features/base/redux] <persistState>: redux state persisted. 32a4d2c744d82607bf3b3637297a71d2 -> a6c2efe4a3a9c5d262536c78c8f83d83 Logger.js:154:22