1468700 - Microphone settings can't be modified when using Jitsi meeting

Status: RESOLVED DUPLICATE of bug 1238038

(Web Compatibility :: Site Reports, defect, P1)

Description

[Cristian Baica [:cbaica], Release Desktop QA]

Attachment: Microphone settings can't be modified

[Affected versions]:
- Fx 60.0.2
- Fx 61.0b13
- Fx 62.0a1

[Affected platforms]:
- Windows 10 x64
- Ubuntu 16.04 x64
- Windows 7 x64
- macOS 10.13

[Steps to reproduce]:
1. Launch Firefox.
2. Go to https://meet.jit.si/ and join or create a new meeting.
3. Open the meeting settings (bottom right side of the screen).
4. Click the 'Device Settings' option.
5. Try to open the 'Microphone' drop-down.

[Expected result]:
- The menu should open and display all the available microphone inputs.

[Actual result]:
- The drop-down doesn't open.

[Regression range]:
- This does not look like a regression since I could reproduce the issue using Fx 34.0a1.

[Additional notes]:
- This issue does not occur on Chrome.

Comment 1

[Mike Taylor [:miketaylr]]

The Microphone dropdown has the following markup, which is different from the Camera dropdown.

<div class="device-selector-trigger-disabled">
  <div class="device-selector-trigger">
  [snip]
</div></div>

Comment 2

[Mike Taylor [:miketaylr]]

Attachment: Screenshot in Chrome

Yeah, options are totally different in Chrome.

Comment 3

[Mike Taylor [:miketaylr]]

Setting to P1 because it's not clear what's up here... Dennis, can you please take a look?

Comment 4

[Dennis Schubert [:denschub]]

Ah, really nice from Jitsi to leave all these debugging messages in place, really helpful.

So, the reason for there not being an Output device is selector is bug 934425. It boils down Jitsi trying to iterate over a list of audio output devices, which in Firefox, unfortunately, is empty. They generate the list by using `navigator.mediaDevices.enumerateDevices`, and if you run `navigator.mediaDevices.enumerateDevices().then(console.log)` in both Chrome and Firefox, you'll see that there are no devices with kind=audiooutput in Firefox, so they don't show that list.

However, they should be able to iterate over the INPUT devices just fine, and I see their code generating a list of these devices just fine. Will have to do more diagnosis, so keeping the ni? alive.

Comment 5

[Dennis Schubert [:denschub]]

Gnah. This is one of the issues where diagnosing from the wrong end leads you nowhere. Given their differences in the console output in Firefox and Chrome, I expected there to be an actual issue with the device enumerating/selection process, so I started following that down up to the frontend rendering pipe. And as it turns out, yes, their internal structure differs quite a bit between browsers - but they expect that.

The fact that the input device selector is disabled is actually not a bug, but .. "a feature". In webpack:///./react/features/device-selection/components/DeviceSelectionDialogBase.js, they can toggle the input device selector with a prop called "disableAudioInputChange", and that is true in Firefox, but false everywhere else.

This prop ultimately gets set via this function in webpack:///./JitsiMediaDevices.js:

> /**
>  * Returns true if it is possible to be simultaneously capturing audio
>  * from more than one device.
>  *
>  * @returns {boolean}
>  */
> isMultipleAudioInputSupported() {
>     return !browser.isFirefox();
> },

This lib is open source, and this check was added in https://github.com/jitsi/lib-jitsi-meet/commit/731b2a7ad57311c3e7cd11522d141d26f3a971ec with a commit message stating

> For audio previewing, some browsers cannot have multiple local audio streams at once.

So this seems to be the core of the issue. Quite honestly, I have no context to this issue, and my knowledge of the Web Audio and WebRTC stuff is limited here. Mike, have you heard of something like that before? I couldn't find something in a quick bugzilla search, so I wonder if we are aware of this.

If this turns out to be a spec-conformant (or widespread..) usage, we should probably support multiple audio streams, and have Jitsi remove that browser check. Otherwise, we might ask them to actually hide the selector, as they do with their output device selector, so it's less confusing to users. But let's wait with outreach until we actually know the reason behind this.

Leaving the [needsdiagnosis] in place until we have figured out the reason.

(And if, by any chance, anyone working on Jitsi reads this: *thank you so much* for shipping a sourcemap to production. This issue would have been more painful if I didn't have access to the uncompressed sources. <3)

Comment 6

[Mike Taylor [:miketaylr]]

Nils, do we have known issues around multiple local audio streams that Dennis mentions in Comment #5? Thanks!

Comment 7

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

This issue is still reproducible.

Comment 8

[Firefox Bug Husbandry Bot]

See bug 1547409. Moving webcompat whiteboard tags to keywords.

Comment 9

[Daniele "Mte90" Scasciafratte]

I tried that yesterday and I wasn't able to change the microphone (I have 2), it is just using the one chosen on the Firefox popup.

Comment 10

[Nils Ohlmeier [:drno]]

Jib, Paul, based on the checkin comment provided in comment #5 does this appear to be a bug on our end, or is Jitsi expecting here some Chrome specific behavior?

Comment 11

[Paul Adenot (:padenot)]

No this is the classic issue where we only allow a single audio input device at once. The solution will come from what alex is doing with setSinkId, as part of the underlying platform work.

Comment 12

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

The mic limitation is real, but preventing mic selection over preview not working seems a poor choice. There's no spec guarantee two or more input devices can be opened at once on every system (Android for example), so jitsi should arguably account for this (like Google Meet or Whereby do).

That said, it was a spec mistake to assume web apps would get this level of system configuration right on every platform and browser, one we're correcting in w3c/mediacapture-main#652 but that's probably a longer-term fix.

Comment 13

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

(In reply to Paul Adenot (:padenot) from comment #11)

The solution will come from what alex is doing with setSinkId, as part of the underlying platform work.

Can we break out the parts that are necessary for this from setSinkId into a separate bug so we can block on it here? Because it's not immediately clear to me why input selection is blocking on output selection. I worry setSinkId might get blocked by UX, so it might be useful to separate the tasks.

Comment 14

[Alex Chronopoulos [:achronop]]

Extracting the parts that we need for this, in terms of source code is not possible. We need to land setSinkId first and then to start planning the multiple mic selection. Opening a bug is easy but they will have to wait. There is a workaround though, that the Jitsi can use. They need to stop first the existing input track and then start a new gUM request using the new device. The important part is to stop the existing track. Then a new gUM to any device is possible. The list of the input devices can be obtained from device enumeration. Whereby.com has been doing that for a long time now.

Comment 15

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

Agree about workaround. On separation, can't we land the backend while keeping the API behind a pref? Just trying to avoid blocking.

Comment 16

[Alex Chronopoulos [:achronop]]

Yeah, I have started landing parts of it.

Comment 17

[ona]

Hello
I tested today with 75.0 (64-bit) Ubuntu canonical 1.0. What I discovered is that I could change micros before entering the room, in the top left area settings icons, but once chosen, inside the room, in the settings, I could not change it. In the Firefox preferences I have not selected "Block new requests asking to access your microphone", so I get asked every time. So I tested also to change the two options that I have when the popup comes thinking that then in the settings I will get only the chosen one in the popup but I always got the first option.

I checked the console in the Webdeveloper inspector and the devices were found when opening the settings in the room

2020-04-19T19:46:07.230Z [features/base/devices] Device list updated:
audioInput:
Built-in Audio Analog Stereo[2Rp9HQ3kcV21bwz5aIZUVGLHvofadfFLDZIajPuGEPw=]
Monitor of Built-in Audio Analog Stereo[REv119rnPOajnJJgmYHHewQ1/viOMvUwylL89Ij3Occ=]
audioOutput:

videoInput:
Laptop_Integrated_Webcam_FHD: I[OMFZkWUjmsqTNSEevIWosiScNPCTlTm9p8+iGFv8GAA=]

Then I checked the html and the microphone selector has class="device-selector-trigger-disabled". I hope this helps :)

<div class="device-selector-label">Camera</div>
<div>
<div class="Droplist-sc-1z05y4v-0 jqXYNP"><div>
<div>
<div class="Droplist__Trigger-sc-1z05y4v-3 cjJUnw">
<div class="device-selector-trigger">
<span class="device-selector-icon icon-camera"></span>
<span class="device-selector-trigger-text">Laptop_Integrated_Webcam_FHD: I</span>
<span class="Icon__IconWrapper-dyhwwi-0 jrFXcq" aria-label="expand">
<svg width="24" height="24" viewBox="0 0 24 24" focusable="false" role="presentation"><path d="M8.292 10.293a1.009 1.009 0 0 0 0 1.419l2.939 2.965c.218.215.5.322.779.322s.556-.107.769-.322l2.93-2.955a1.01 1.01 0 0 0 0-1.419.987.987 0 0 0-1.406 0l-2.298 2.317-2.307-2.327a.99.99 0 0 0-1.406 0z" fill="currentColor" fill-rule="evenodd"></path></svg>
</span>
</div>
</div>
</div>

<div class="device-selector-label">Microphone</div>
  <div class="device-selector-trigger-disabled">
    <div class="device-selector-trigger">
      <span class="device-selector-icon icon-microphone"></span>
      <span class="device-selector-trigger-text">Built-in Audio Analog Stereo</span>
      <span class="Icon__IconWrapper-dyhwwi-0 jrFXcq" aria-label="expand">
        <svg width="24" height="24" viewBox="0 0 24 24" focusable="false" role="presentation"><path d="M8.292 10.293a1.009 1.009 0 0 0 0 1.419l2.939 2.965c.218.215.5.322.779.322s.556-.107.769-.322l2.93-2.955a1.01 1.01 0 0 0 0-1.419.987.987 0 0 0-1.406 0l-2.298 2.317-2.307-2.327a.99.99 0 0 0-1.406 0z" fill="currentColor" fill-rule="evenodd"></path></svg>
      </span>
    </div>
  </div>
</div>

Comment 18

[ona]

I found this bug reported in Jitsi
https://github.com/jitsi/jitsi-meet/issues/2835

Comment 19

[Raul Bucata]

The issue is still reproducible. The drop-down menu for the microphone input does not open and does not display all the available microphone inputs.

https://prnt.sc/nw8SKUfTngcn

Tested with:

Browser / Version: Firefox Release 99.0.1 (64-bit)/ Firefox Nightly 101.0a1 (2022-04-12) (64-bit) Chrome Version Version 100.0.4896.88 (Official Build) (64-bit)
Operating System: Windows 10 PRO x64

Notes:

1. Reproducible regardless of the status of ETP.
2. Reproducible on the latest build of Firefox Nightly.
3. Works as expected using Chrome.

Comment 20

[C.M.Chang[:chunmin] | PTO]

Hi Raul, can you check if you can still reproduce this? It seems this should be fixed by bug 1238038 comment 65

Comment 21

[Raul Bucata]

Thanks for the ping. The drop-down menu now responds, but only 1 option is available, compared to Chrome, which has 3. Also, the "Audio output" option seems to be present now in Chrome, but Firefox does not have this option. If the initial bug has been fixed (the drop-down menu does work), but a new bug is present (just 1 option is shown), I am more than glad to submit a new bug regarding the Microphone options and the missing output option.

Firefox:

https://prnt.sc/vsKEL1tO-QgV
https://prnt.sc/4ALSdGBnobzQ

Chrome:

https://prnt.sc/WS4qgXiF6Cy7
https://prnt.sc/SgCB6J9R2WDZ

Tested with:

Browser / Version: Firefox Release 101.0. (64-bit)/ Firefox Nightly 103.0a1 (2022-06-02) (64-bit) / Chrome Version Version 102.0.4004.63 (Official Build) (64-bit)
Operating System: Windows 10 PRO x64

Comment 22

[Paul Adenot (:padenot)]

Looks like Chrome is incorrect here, it shows three times the same device:

• One entry for the default audio device
• One entry for the default communication device
• One entry for the device itself

but it's three times the same device.

Comment 23

[C.M.Chang[:chunmin] | PTO]

(In reply to Raul Bucata from comment #21)
Hi Raul, could you check if those three devices are the same (#comment 22)? If those three are the same, then we don't have any bug here and we can close the bug :)

On the other hand, the output device selection is related to setSinkId, which is unrelated to the problem mentioned in this bug. It looks like Bug 1769985 is the same problem.

Comment 24

[Raul Bucata]

Yes, I can confirm that in Chrome, the listed 3 devices are basically the same device being listed 3 times over, in different categories/device properties.