PulseAudio is now required in Firefox Nightly
bugzilla.mozilla.org
bugzilla.mozilla.org
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.
* https://bugs.chromium.org/p/chromium/issues/detail?id=178101
You can also set these sysctl's:
hw.snd.latency_profile=0
hw.snd.latency=3
int cooked = 0;
ioctl(fd, SNDCTL_DSP_COOKEDMODE, &cooked);
And the code to output OSS audio is way simpler and easier than WASAPI, ALSA, and Pulse. Even easier than Pulse's simple API wrapper.
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.
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.
Think about it this way: Okay, you got burned by Pulseaudio. But why was it your job to debug these issues? Why was it your job to decide to go back to Alsa, rather than fix them?
Now when a distribution decides to provide multiple configurations then it's also the distribution's responsibility to ensure everything works correctly. When a distribution like Gentoo decides to shift that responsibility to the user, expect to be burned - but don't expect upstream to be friendly to you.
Same for systemd. No end user should care. System administrators sure will care, but 99% of sysadmins I've talked to love systemd... so that's not the issue.
As a Linux enthusiast I'm sorry that this is the state of things, but this is the price we pay for customizability. This is the price of being able to change every little setting, every little modular bit of software, every library providing imperfect 90% compatibility with every other library.
Pulseaudio/systemd complaints are IMHO a symptom of a far worse overarching issue with Linux. They showcase the failures of direct democracy. The lack of context that users have and give. When a user says "I want to stay on Alsa", what they really mean 99% of the time is "I had a bad Pulseaudio experience that one time, and I heard a ton of bad things, so give me Alsa". Those same users don't understand the difficulties of supporting, in alsa, configurations that they don't necessarily use such as bluetooth headsets; configurations that other users ask for.
Thus, the failure of direct democracy: "I want what works for me, not what works for everybody".
Because it's his computer? Who else's job might it be? He only has a few options: fix it himself, pay someone else to fix it, convince someone else to fix it for free, or do without sound.
It's the same with less knowledgeable users, except they don't have the option to fix it themselves.
Except we just said it doesn’t work for everybody. PulseAudio breaks audio on my computer. ALSA just works. Until PulseAudio also just works, I don’t want to use it.
- ALSA to PulseAudio routing works much better than most native ALSA drivers. This used to be not true a bunch years back. (alsa-pulse in alsa-plugins) It is the default in many important distributions.
- You can also force PulseAudio to not take over hardware devices and still use default or other ALSA device. This requires disabling a hardware detect module so you will lose some hotplug potential.
- There are also ways to make it interoperable with Jack. Simple in fact. Works better than all ALSA to Jack approaches in my experience.
- One remote possibility is that you are using a sound card which has a broken ALSA driver. PulseAudio tries to use advanced features such as mmap, rewinding and buffer monitoring to reduce latency and improve performance. If one of those pieces is broken in some subtle way, it could fail. (generally crackle) In this case, this needs debugging work in ALSA side. Other applications also use some of those features.
ALSA does. It used to have configuration problems but that's not the case any more.
After more than 20 years of Linux, I have very low expectations concerning the state of sound in Linux, but PulseAudio does not even fulfil them. PulseAudio is now banned from any of my computers.
So...consider me a satisfied Pulse user, I guess, except I don't even think about it. For me, Linux audio is just a solved problem.
Then oss4 is banned from the kernel, and asking about it got me even banned on spot without explanation on some irc channels and forums.
Then people try to convince me linux is ready for desktop adoption and people stay on windows because inertia...
OSS4 has a different set of drivers. It sucks at both latency and maintenance though in all of them.
Two reasons:
1. I was at the time supporter at ubuntuusers.de, the german Ubuntu forum
2. When Ubuntu moved to pulseaudio it botched the upgrade. Rather, PA just sucked and did not work on many systems, there was not much Ubuntu could've done better apart from sticking to ALSA or moving to another soundserver.
Now, currently on my system it's because I decided actively to not use specific parts of the "modern" Linux system. No sytemd, no pulseaudio. I'm working on this machine and I want software that works.
> Those same users don't understand the difficulties of supporting, in alsa, configurations that they don't necessarily use such as bluetooth headsets
This is exactly the area where my laptop system with PA makes issues. The bluetooth headset just does not work reliably. It works sometimes and sometimes not.
Yes, it's the price of customizability, you're right about that. But the solution of moving to complicated and broken bigger frameworks, and additional layers of abstraction, just is no solution. Make the stuff that does not work work – didn't the BSDs stay with OSS and now have a really good soundsystem? Or convince people of better solutions by making better solutions that actually work, instead of shoving broken software (PA) or broken software with innacceptable design decisions (systemd, binary log) via distro upgrade without provided alternative down people's throat. The mainstream distros are making it wrong.
That might be easier said than done. My 10+ year old Pulseaudio showstopper bug has produced at least one patch, but as of yet that patch has not been accepted.
So an important point... It isn't just that Pulseaudio is buggy, we have no real way of resolving the issue without a fork.
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.
> It merely reduces the userbase to those whose systems look like the developers
Pulseaudio is included by default in almost every Linux distribution. Certainly in every major Linux distribution. This is Mozilla not catering to the 1%. I'm sorry but I cannot see a world in which that decision is incorrect.
I found that of all the people complaining about, for example, systemd, very few actually stepped up to actually maintain the batshit-insane ecosystem of init scripts of their distributions. Those that did, quickly gave up and admitted they were wrong - we had a few of those in Arch Linux when we moved to systemd.
For Pulseaudio, it's the same thing. Who's stepping up to improve the state of Linux audio? In fact, who, of those complaining about pulse, even have a clue about the state of Linux audio and how much of a pain it is to develop for it?
I agree. It's a natural reaction for a company struggling to find its purpose. I hope for all our sakes it helps Mozilla survive.
> Who's stepping up
Well, that's the crux of the problem. Very few people are qualified. Those that are qualified almost universally do not have the backing of Red Hat. It is the opinion of many that both pulseaudio and systemd achieved market dominance because of politicoeconomic reasons, rather than a technological decision-making process. It is very, very hard to prove otherwise... which is why we get these ridiculous religious wars on the topic.
Personally, I don't care. The bugs I've run into in both pulse and systemd are always products of naivete rather than some ficticious malicious plot. Growing pains, like all other projects undergo. The problem we are starting to have is that we are losing portability in the process. The more software requiring libpulse and libsystemd, the more difficult it is for novel approaches to survive.
A posix capability layer is one thing. How does a new player enter the game, when libpulse and libsytemd have no specification? It feels a little like embrace/extend/extinguish.
I have no reason to move away from linux. I have no problem using systemd and pulseaudio on all my systems. But I do understand why some might miss the days when the barier was lower. Dismissing and/or demonizing the people who think that way isn't particularly productive, and neither is telling them their opinions are irrelevant. I hope we move past "if you don't like it reimplement it yourself" one day. The ability to do so was what gave us systemd and pulseaudio, but the requirement that it be done before you can be taken seriously doesn't really add much value.
It's also an insane request because it just can't be done. If I would want to provide an alternative to systemd for the mainstream distros, my first poinft of work would be to implement systemd. Because the environment around me assumes systemd, apart from some safe enclaves.
If I were to provide an incompatible alternative I'd have to win the political war to have it be used or even just considered. Given how upstream looks today that is impossible, even if my solution were excellent. And in that space, nothing can compete against organized paid developers.
And still: People did step up. There still is OpenRC, for example, which is what I'm using. There are the forks that work and provide alternatives. But Linux is more splintered than ever because of that.
The situation with PA and ALSA is better, because ALSA always still worked (I know, because of being an underlying layer, but also without PA, which is nice).
Sometimes garbage on top of garbage is the easiest path towards a practical solution. I just want my desktop to make noise and not make me go deaf.
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.
You were right about that, I tested it in another comment on here. I thought that resampling would happen within a kernel driver or something. But no, apparently when an app uses the alsa library, the functions that resample will happen within the app generating the sound (and thus in userland).
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.
root@t61:~# dpkg --get-selections |grep -i "pulse\|alsa\|sound"
gstreamer0.10-alsa:amd64 install
gstreamer1.0-pulseaudio:amd64 install
libasound2:amd64 install
libasound2-data install
libclalsadrv2 install
libpulse-mainloop-glib0:amd64 install
libpulse0:amd64 install
libsdl-sound1.2:amd64 install
libsoundtouch0:amd64 install
libzita-alsa-pcmi0:amd64 install
root@t61:~#
You say alsa uses more CPU than PA? But how can I verify that? Even if alsa runs entirely in kernel land, it would show up in regular top. But comparing the default alsa setup with a default PA setup, top shows very differently.
defaults.pcm.rate_converter "samplerate"
I went ahead and installed pulseaudio, (there was some good info here[0]), I set up ALSA to by default use PA through /etc/asound.conf[1]
Rebooted and everything seems to work fine so far (though I haven't tried suspending on the laptop which seems to be trouble for some). Ironically when I play stuff on soundcloud through firefox, the CPU usage for one of the FF process would always hang around 50%, now it is hovering between 20-30%, so perhaps it even lowered that usage as well. audacious uses about 6-7% CPU now as well.
The default resampling of pulseaudio works good too. You can try playing this dial tone file that has a hidden 19khz tone in it[2]. If the resampling is not done good enough, you'll end up with an audible interference pattern (it would show up on ALSA, but not with pulseaudio now)
[0] https://wiki.archlinux.org/index.php/PulseAudio
[1]https://git.archlinux.org/svntogit/packages.git/tree/trunk/a...
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.
I've tried to figure out what exactly the linux sound system looks like under the hood, but I really can't. And then I come across pages like this: http://askubuntu.com/questions/581128/what-is-the-relation-b... that flat out state PA just sits on top of ALSA. So in my mind, if everything just works with out PA, why install it?
Yes, PA sits on top of ALSA. But PA does have other features, for example sending audio over the network, which is something that I have used on systems that don't have soundcards (e.g. Windows Subsystem for Linux) and for routing all my audio through my OpenWRT router which is connected to my high quality stereo (which allows all computers in my room to output audio to speakers without any cables). Also things like grabbing audio out from one app and recording to audacity is easy with PA.
That being said, I'm the type of person that prefers minimal systems, in which case I usually stick to LXDE sans-pulse, and if I do need advanced audio processing, then I go with Jack.
Nope. Sleep mode, no matter what distro you use, causes issues from 2008 until today [0][1][2]...[n]
[0] https://wiki.archlinux.org/index.php/PulseAudio/Troubleshoot...
[1] http://askubuntu.com/questions/762816/ubuntu-16-04-changes-s...
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.
...phew!
Uh?
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.