Open Bug 1547447 Opened 6 years ago Updated 4 years ago

Firefox does not expose jack audio capture ports for microphone.

Categories

(Core :: Audio/Video: cubeb, defect, P5)

66 Branch
defect

Tracking

()

People

(Reporter: u603404, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.88 Safari/537.36 Vivaldi/2.4.1488.35

Steps to reproduce:

  1. Compile firefox with jack support on gentoo linux
  2. Visit https://www.onlinemictest.com/
  3. Test microphone by selecting "JACK capture"

Actual results:

Firefox doesn't expose a jack capture port for microphone. There is no sound input.

Expected results:

It should expose a jack capture port for microphone.

Moving this over to Build System component so developers can take a look at it.
Unfortunately, I can't test this since I don't have the knowledge to compile firefox for gentoo linux nor the Gento linux OS installed.

Component: Untriaged → General
Product: Firefox → Firefox Build System
Component: General → Audio/Video
Product: Firefox Build System → Core

:kinetik, is this something you have familiarity with?

Flags: needinfo?(kinetik)

The JACK backend is unsupported and unmaintained, sorry. @zamaudio worked on it a few years ago, but there has been no interested in maintaining the backend recently. I don't recommend trying to use the JACK backend unless you're interested in maintaining it or debugging and fixing issues you run in to.

Flags: needinfo?(kinetik)
Component: Audio/Video → Audio/Video: cubeb
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P5

I had the same issue and was able to work around it by playing some audio from another page. This causes firefox to register itself as a JACK client, and then the microphone feature starts working.

The backend code works just fine, only whatever trigger gets run when you have audio output isn't getting run in the audio input case.

What's more interesting is that when I play audio after opening the recording site, the system recording input gets connected with firefox's capture input. That suggests to me that the recording code is queuing up the JACK connection without initializing the client, and whatever code causes the JACK client to be created is then also creating the actual input connection from that.

The original reporter didn't specify whether or not firefox was already registered as a client with the JACK server, so it's unclear if my experience aligns with theirs.

Flags: needinfo?(crockabiscuit)
Severity: normal → N/A

I'm touching this so it doesn't show in our triage queries.

Modification and improvements to the Jack backend are certainly welcomed, it's community supported (we do code review and patch merging etc., but are not actively improving it).

This happens at https://github.com/kinetiknz/cubeb (there are a few people discussing improvements to the Jack backend in the issue), that is upstream.

Severity: N/A → S4
Flags: needinfo?(crockabiscuit)

With https://appr.tc/ on Firefox 83.0 on Gentoo Linux, it often manages to "just" kill the JACK server when it tries to connect WebRTC/microphone to "JACK capture" after I played audio from another tab (the last part is there to circumvent the issue with "firefox fails to register itself as a JACK client").

Otherwise, I have the same situation as John Ferguson, I need to play some other audio first, so that firefox registers itself as a JACK client.

You need to log in before you can comment on or make changes to this bug.