Closed Bug 1331526 Opened 6 years ago Closed 3 years ago

Add option to disable JACK in Linux and/or prefer PulseAudio or ALSA over JACK

Categories

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

50 Branch
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: JimiJames.Bove, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161130210124

Steps to reproduce:

Upgraded Firefox from 50.0.2 to 50.1


Actual results:

No audio in the browser used PulseAudio, and instead used JACK (I run both at once), leaving me without the extra volume controls and ease of use that I get from PulseAudio and require in a non-audio-intensive program like Firefox.


Expected results:

Firefox should have recognized I was running PulseAudio and preferred that over JACK, and provided options, at least in about:config, to let me decide what audio server to use when (being more inclusive because I have seen other users mention they want to make it just use ALSA instead).

I can't imagine that anyone who's running Pulse + JACK would ever want Firefox to use JACK. If you use JACK and yet love Pulse so much that you also keep Pulse running, that means JACK is probably meant for heavy-duty sound operations that may need to run in realtime, like a DAW. Firefox is not a DAW. Now, I have to choose between not updating Firefox until this gets sorted out, or recompiling with a patch every time a new version comes out.

An example patch that solves most of this issue, and all of the parts of it that affect me, can be found here: https://bugs.archlinux.org/task/52183#comment154508

In that link is also another patch dealing with the fact that Firefox just automatically connects to the first 2 JACK ports available, which is terrible for plenty of JACK users, as plenty of soundcards dont set assign those ports to the computer's speakers and disconnecting those connections yourself in any remotely automatic way is extremely cumbersome and script-heavy. But that should probably be filed as a separate bug.
Sorry, wrong link. The proper one is https://bugs.archlinux.org/task/52183#comment154442
Component: Untriaged → Audio/Video
Product: Firefox → Core
Matthew - do we build/use Jack by default on Linux?   I thought Jack support was optional...
Component: Audio/Video → Audio/Video: cubeb
Flags: needinfo?(kinetik)
Whiteboard: [needinfo 2017/1/17 to kinetik]
(In reply to Randell Jesup [:jesup] from comment #2)
> Matthew - do we build/use Jack by default on Linux?   I thought Jack support
> was optional...

It's not enabled in official builds and we (Mozilla) don't support the JACK backend at all.  Distributions can build with a different configuration, obviously, but if they're enabling stuff outside of the defaults they should be prepared to support those changes.

I do think having the JACK backend first in the list of backends to try (if it's enabled) is a bad idea, and I think I disagreed with doing so back when it was added.

My simple recommendation is to disable the JACK backend, unless the distribution enabling it is prepared to support it with patches.

Moving the JACK backend (if it's enabled) lower in the priority list would be a good change.

Providing a way to select or override the backend is something we want (with lowish priority) anyway, so that'd also be something worth exploring.
Flags: needinfo?(kinetik)
After I started this report, somebody in the Arch Linux bug report mentioned that it should probably be filed in cubeb's Github (https://github.com/kinetiknz/cubeb) instead (I didn't know at the time that Firefox's sound backend was cubeb, or that cubeb was a separate project). Should I do that? The fact that the bug just had its component set to cubeb makes me think maybe you guys are already on that?
Rank: 55
Priority: -- → P5
Whiteboard: [needinfo 2017/1/17 to kinetik]
Confirming; we'd take patches per kinetik's comment (to upstream cubeb mostly, though)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Sorry, I'm having trouble understanding that sentence. Are you saying that if I reported it to cubeb and kintetik came here with a patch, you'd take that? Should I file a bug report there so that can happen? Or are you saying something else?
(In reply to JimiJames.Bove from comment #6)
> Sorry, I'm having trouble understanding that sentence. Are you saying that
> if I reported it to cubeb and kintetik came here with a patch, you'd take
> that? Should I file a bug report there so that can happen? Or are you saying
> something else?

It would be better reported against cubeb (though really it's largely the same people).

It is not used by default on Firefox.  We (or really the cubeb project) would take a low-risk patch if someone provided one (in line with kinetik's comments above; thus my making it a P5 (effectively a priority of "we (Mozilla) would not plan to put resources on it" (at least for a p5's own sake; other work we're doing always might fix it or be easier if we fixed it).
I've pushed a simple PR upstream to change the ordering as discussed: https://github.com/kinetiknz/cubeb/pull/214  It's probably identical to the suggested patch in the Arch bug tracker.

The media.cubeb.backend pref exists (since bug 1341238) for overriding the default. I don't think there's anything left for this bug.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED

Any reason that pref needs to remain hidden by default? Would have been most helpful to know its existence.

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