PulseAudio is now required in Firefox Nightly

https://bugzilla.mozilla.org/show_bug.cgi?id=1247056#c163

by esaym • 10 years ago

42 61 10 years ago

bugzilla.mozilla.org

It sounds as though the code for plain old ALSA is still there though, so if you're building from source you can still enable it

...phew!

SysArchitect• 10 years ago

How is sound handled on FreeBSD? Or is FreeBSD going to be required to port and ship PulseAudio?

Sanddancer3• 10 years ago

PulseAudio is cross-platform.. For FreeBSD in general, it uses further development of Open Sound drivers, which have things like in-driver mixing that Linux drivers under Alsa even lack.

wott2• 10 years ago

things like in-driver mixing that Linux drivers under Alsa even lack.

Uh?

digi_owl5• 10 years ago

BSDs still use OSS, afaik. Linux replaced OSS with Alsa over licensing issues.

kasabali• 10 years ago

Linux replaced OSS with Alsa over licensing issues

I've only done light reading on the history but I suspect it is more like linux devs used license change of OSSv4 as an excuse to satisfy their NIH syndrome. They could've continued to develop existing OSS codebase as BSD's did but they chose to write ALSA from ground with a totally different design.

Etheryte• 10 years ago

The decisions Firefox has made over the last years make less and less sense.

esaym6• 10 years ago

I'm still happy with them as a browser. But not sure now if they force PA on me. I've tired to use/install it (PA) before, but I couldn't stand the PA process hanging around in the background eating 20% of my cpu...especially on laptops.

Alupis2• 10 years ago

PA process hanging around in the background eating 20% of my cpu

Sounds like a misconfiguration if anything.

For a typical user - PulseAudio "just works" and there's no more to it than that. It does make large improvements over just plain ALSA, and as far as I know, is included in all the major Linux distros... so many folks use it and never even know nor think about it.

ilikejam• 10 years ago

That CPU use is resampling to match the sound card rate. If PA isn't doing it, your apps will be instead. Either way, it's going to take some cycles.

Asooka• 10 years ago

Protip: use pulse on top of jack. I can't get to my PA config right now, but the gist is

1) copy the default config to ~/.pulseaudio

2) edit out the device autodetection and add in loading just the jack module

3) if you have more than a single device, either add it to the pulseaudio config (i.e. bluetooth comm device for use with skype) or use alsa_in and alsa_out to connect an additional alsa device to jack, then add the device to the pulse config as an additional source/sink pair

4) keep the default alsa device pointing to an alsa-pulse bridge. Yes, this sounds crazy when you can just layer alsa on jack rather than on pulse->jack, but this way you get the per-application volume controls, which are one of the few really good features of pulse. If you don't care for per-application volume controls, just layer alsa on top of jack directly.

With this setup, pulse acts as a simple bridge to jack and jack does a much better job of controlling your sound card, remixing, etc. I have a hunch that the absolute single best sound setup on linux would involve patching jack to basically act like pulse w.r.t automatic device management and then add the native pulse protocol to it.

natermer2• 10 years ago

I couldn't stand the PA process hanging around in the background eating 20% of my cpu...especially on laptops.

That's likely a artifact of you needing to configure these things yourself and not doing a very good job.

This is where distros that force users to configure basic features like audio do a real disservice. In 2016 nobody should be configuring anything to do with audio unless they are doing audio production. If a problem comes up the only thing that should be done is to file a bug so it can be fixed. Working around bugs by trying to configure something is nasty business, but unfortunately when distributions don't do the work it forces users to do it.

Going from a system that is configured to use Alsa and then trying to go to Pulseaudio is a PITA and is surprisingly difficult to get right.

Here are the basic steps:

* First you need to undo the damage caused by the usage of things like 'alsamixer'. Alsamixer does a very poor job exposing the low-level mixer controls on your hardware. A lot of the controls are only partially functional and turn on or enable some configurations in spooky ways that can't be undone. Bad configuration settings caused by things like alsamixer cause endless headaches because it jacks up Pulseaudio's ability to configure the hardware correctly sometimes.

To prevent current settings from carrying over to the next reboot you need to locate your 'asound.state' file were the alsa service stores your configurations between reboots. Delete that and symbolically link it to /dev/null, reboot, and then turn it back to a regular file.

* Find all your Alsa 'hacks' and get rid of them. Your .asoundrc files and the like. You definitely do not want to be doing things like setting bitrates or buffers or the like using Alsa configuration files. Get rid of dmix and any other alsa plugins you have configured. They are counter productive. You can do that by configuring PulseAudio if you really want to.

* Make sure that Pulseaudio is using hardware device directly and not going through something like 'dmix'.

* make sure that your init system is doing things correctly and that no sound gets kicked off before Pulseaudio latches to the hardware. Modern hardware has no hardware mixing features because they increase cost and lower audio quality.

* Make sure your software is configured to use Pulseaudio directly whenever possible. This can be very difficult, unfortunately, because there are a huge numbers of audio libraries and whatnot that applications use and they are all configured differently.

If CPU usage is still a issue after you have it setup initially you can control the type of resampling algorithm you use.

Alsa with DMIX uses as much CPU as Pulseaudio on 'Trivial' resampling method. A lot of the difference in cpu usage is psychological. When the default configuration of Alsa burns up cpu with resampling it doesn't show up in things like 'top'.

On a laptop, with Pulseaudio configured correctly, you should see a slight reduction in energy use.

scrollaway3• 10 years ago

There's plenty of things to complain about in Mozilla's and Firefox's development decisions (as I just did in another thread). This is not one of them.

It's far easier to depend on libpulse and have better and more consistent audio support across the board than to have to maintain a bunch of different backends, each with their own set of bugs, some of which are only ever reproducible by one dev on their one machine.

It's also worth noting that at this point, the only users that would complain about this change are either those that have an irrational fear of all things pulseaudio, or those that happen to use distributions that have an irrational fear of all things pulseaudio. It's a better developer experience than alsa and at some point, people will have to move on.

I don't understand, though: On Windows or OSX, when there's massive refactorings and changes in dependencies of builtin software, nobody bats an eye. But on Linux, when something like systemd or pulseaudio comes along, eeeeeverybody's gotta bikeshed about it.

Edit: My comment was unfair. Clarified.

onli3• 10 years ago

On Windows or OSX, when there's massive refactorings and changes in dependencies of builtin software, nobody bats an eye.

In Windows and OSX, the builtin software is not stuff we can influence. When Apple decides to use another soundserver that is what happens. There are no different expectations. Linux is a different beast.

Take me as example. I just got burned often enough by pulseaudio that I really don't want to try it again. When it was introduced there were countless support threads in the linux forum I frequented at the time with broken systems, and also my own did only work when I reverted to ALSA. Also later, when everything was supposed to work, PA just did not work for me. Yes, I'm using it by now on my laptop, but it's not like that is a flawless experience – and I highly assume PA is at least partly responsible for the issues with the sound system on there.

Now, it's not only pulseaudio. See what the Gentoo wiki writes (https://wiki.gentoo.org/wiki/PulseAudio):

This is the only supported configuration by upstream and Gentoo developers.
PulseAudio uses udev and ConsoleKit to dynamically give access to the soundcards to the currently "active" nr. When running Systemd this will be handled without needing ConsoleKit.

ConeoleKit is unmaintained and to my understanding bloat that is just completely unnecessary, especially on my single user desktop system. And of course systemd won't come on my main system, I completely oppose it. Relying on PA means moving into the wrong part of Linux.

Maybe it won't be a big problem in the end, with the ALSA code still being available. Still, not a good thing, and in my eyes indeed a development decision one can complain about.

stonogo2• 10 years ago

Discussing a change in assumptions that alters the core requirements of the most-used user-facing application on the operating system is hardly 'bikeshedding.'

Requiring additional third-party software will never result in 'more consistent' behavior. It merely reduces the userbase to those whose systems look like the developers, and causes your project to be beholden to the whims of the upsream devs.

This is not some architectural decision with a measurable quality impact; it is another abdication on Mozilla's part. We will see more and more of this as their current decline continues. I happen to have no problems with libpulse, but it's pretty clear Mozilla is trying to throw as much as possible over whatever fence they can find. See also Project Mortar.

Sanddancer3• 10 years ago

Relying on libpulse is just relying on another layer of the shit sandwich that is the Linux audio stack. Windows and OS X, when they've revamped their audio APIs, the older stuff tends to still work, and tends to be able to take advantage of some of the improvements. Linux audio, on the other hand, is a layer of pulseaudio atop a layer of alsa's userspace components, which is atop a layer of alsa's driverspace components. Instead of people doing things right, and fixing the interfaces that already existed, they added more and more layers of latency-inducing, cpu consuming crap.

natermer2• 10 years ago

Having working audio input (microphones) and using Alsa are often diametrically opposed goals.

If your use case is very simple Alsa playback is fairly trivial. But anything beyond that usually is going to require significant configuration on the user's part and when the user needs to configure things it usually isn't going to be done very well; which is going to cause endless headaches for things like Mozilla project.

namecast• 10 years ago

For those of you dead set against using PA, you may want to look into this project to emulate PulseAudio support for ALSA: https://github.com/i-rinat/apulse

jay-anderson2• 10 years ago

Nice. I dread having to do any audio configuration on linux. I originally hoped that pulse audio would move linux in the right direction, but in my experience things are as messy as ever with one more ugly wart to worry about. It's made me seriously consider purchasing a mac.

feld• 10 years ago

Audio works great on FreeBSD

tomjakubowski• 10 years ago

I'm not totally sure what Firefox did here, but requiring libpulse isn't the same as requiring PulseAudio. And the comments in that linked issue suggest that this merely introduces a required dependency on libpulse.

The standard Chromium package on Arch Linux requires libpulse, but I run it just fine on my laptop with no PulseAudio daemon. It seems like libpulse will fall back to ALSA if the PA daemon isn't running.

edit: disclaimer: I know very little about audio on Linux, merely describing my own experience and speculating wildly.

upofadown2• 10 years ago

A quick search revealed no fallback to Alsa built into libpulse. Here is the discussion about Chromium where they are talking about doing their own fallback to Alsa:

* https://bugs.chromium.org/p/chromium/issues/detail?id=178101

jwildeboer• 10 years ago

Isnt PulseAudio Part of systemd anyway nowadays? SCNR ;-)

riffic• 10 years ago

I got nothing against this. Desktop Linux needs to grow up.

digi_owl5• 10 years ago

It had already back in the early 2000s, now is turning senile...

digi_owl5• 10 years ago

In one word: NUTS.

PulseAudio is now required in Firefox Nightly

Related Stories