1936667 - Sound input does not work when no headset is plugged in (Linux ARM)

Status: RESOLVED INVALID

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

Description

[Daniel Bodea [:danibodea]]

Note

• When the user joins a WebRTC meeting (on a MacBook M1 Pro with no headset) and observes the permission door-hanger, he might notice that the input device shown is incorrect: "Monitor of MacBook Pro J316 Speakers".

Found in

• Nightly v135.0a1 aarch64

Affected versions

• Nightly v135.0a1 aarch64 (.tar.xz)
• Release v133.0.3 aarch64 (SNAP canonical)

Tested platforms

• Affected platforms: Ubuntu24.04.1 ARM + aarch64
• Unaffected platforms: non-ARM devices
• not tested on Windows/MacOS ARM devices

Steps to reproduce

1. Load a WebRTC test page:
   https://mozilla.github.io/webrtc-landing/gum_test.html
2. Click on "Microphone" or "Camera & Microphone" buttons.
3. Observe the input device displayed on the permission door-hanger.

Expected result

• The input device displayed is correct.

Actual result

• The input device displayed is incorrect: "Monitor of MacBook Pro J316 Speakers". It shows an audio output device, apparently.
• This issue does not occur on Chromium since it displays the error: NotFoundError: Requested device not found. (Since no input device is recognized in Ubuntu's settings)

Regression range

• This is probably not a regression, but a system environment issue, audio input drivers.
• Also occurs in Release v133.0.3 aarch64 (SNAP canonical).
• Does not occur on Ubuntu 22.04 x64 (non-arm).

Additional notes

• I suspect that this issue might be caused by the improper test environment. The test machine provided for testing: Ubuntu Asahi installed on an Apple MacBook M1 Pro.
  • Ubuntu Asahi reported some know issues with sound here
  • Bug 1935655 is also related to sound and might NOT be caused by Nightly.
  • When no headset is plugged into the device, no Audio Input Device is recognized in the Ubuntu's settings.
  • When a TTRS headset is plugged into the device, then "Headset Microphone - Built-in Audio" is recognized in Ubuntu's settings AND the browser needs to be restarted in order to recognize the new input device. Chromium does not need to restart in order to recognize the new headset.
  • I need information on how I could investigate the actual cause of this issue, especially since there is a high chance it is not a Firefox issue.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 2

[Johan Lorenzo [:jlorenzo]]

I suspect that this issue might be caused by the improper test environment.

I agree. I'm moving this bug to the WebRTC component to get the opinion from someone on this team.

Comment 3

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

(In reply to Daniel Bodea [:danibodea] from comment #0)

• This is probably not a regression, but a system environment issue, audio input drivers.

I agree: to me it looks like this is because the MacBook has only an audio output device and no inputs (or at least no inputs that Asahi has drivers for yet; I'd assume there's a built-in microphone but maybe there's some fancy DSP that needs to be reverse-engineered).

The “Monitor of…” loopback inputs do appear as choices in Firefox's microphone prompt on the other systems I have access to that use pulseaudio/pipewire, but those systems have at least one real input device which is first in the list.

Chrome appears to filter out those monitor inputs completely; maybe we could do that too but that would be a question for the WebRTC peers.

Comment 4

[Andreas Pehrson [:pehrsons]]

That's correct. We expose monitors on linux and Chrome doesn't. The reported behavior is expected.

As to why we expose monitors, IIRC we consider them enablers of certain use cases. When we have an alternative solution for those use cases we could consider dropping them. getDisplayMedia({audio: true}) seems like a fitting alternative.