PulseAudio is now required in Firefox Nightly(bugzilla.mozilla.org)
bugzilla.mozilla.org
PulseAudio is now required in Firefox Nightly
https://bugzilla.mozilla.org/show_bug.cgi?id=1247056#c163
9 comments
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
* https://bugs.chromium.org/p/chromium/issues/detail?id=178101
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
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.
Audio works great on FreeBSD
FreeBSD audio has been amazing for as long as I've used it.
You can also set these sysctl's:
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.
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.
I hadn't even considered any of the BSDs (it's for servers in my mind - a stereotype :) ). I'm definitely going to give it a go. I have a small recording setup in a spare room to play with which is currently running linux.
The decisions Firefox has made over the last years make less and less sense.
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.
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.
> 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.
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.
Here's the thing though, none of that is supposed to matter. End users most definitely are not supposed to care what their sound server is. These are decisions that, ideally, are taken by the distributions.
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".
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".
> Okay, you got burned by Pulseaudio. But why was it your job to debug these issues?
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.
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.
Exactly what I was thinking. I've never owned a Linux computer where I was promised any kind of support. If something goes wrong, I get to fix it or do without, so I end up caring about the inner workings much more than I would with a Windows computer.
> "I want what works for me, not what works for everybody"
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.
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.
This is because you are unable to configure PulseAudio properly despite the very good documentation it has.
(It could use better one for the internals though.)
- 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 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.
Pulseaudio never worked properly on any of my setups, across several machines, several distributions and many years. Problems vary: no sound at all, sound stopping after a while, sound interrupted by silences, insane CPU consumption for little or nothing and I probably forgot a few.
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.
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.
Ok, but here's a counterpoint: for five years now I've been running Mageia Linux on a variety of laptop, desktop, whatever, all with Pulse and I've never had a problem. Like, none. I wouldn't even know how to diagnose it if I did, but since it never happens, I never think about it.
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.
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.
For me, the pro audio part could use more work. Dealing with underruns in Jack is annoying and mostly kernel fault. (Because ffado FireWire works great.)
Last time I had a linux desktop for both work and fun, what worked was oss4. Not pa, not alsa.
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...
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...
That last time must have been more than 10 years ago and/or you were using a sound card which had no drivers made yet. (or finished)
OSS4 has a different set of drivers. It sucks at both latency and maintenance though in all of them.
OSS4 has a different set of drivers. It sucks at both latency and maintenance though in all of them.
> 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?
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.
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.
Iirc, the OSS thing was a license issue rather than a technical issue. the BSDs, being under that MIT license, do not have to deal with how to ensure future freedoms.
>Why was it your job to decide to go back to Alsa, rather than fix them?
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.
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.
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.
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.
My own complaints I mentioned are about Project Mortar. Like I said, Mozilla does plenty wrong.
> 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?
> 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?
> 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 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.
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.
> 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).
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).
Moving the alsa compatibility code from inline to a third-party library doesn't sound like it alter "the core requirements" by much. Its a 255078 byte package in debian, while firefox itself is ~50MB.
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.
While you might be right (I don't know, I have used JACK, alsa, and pulse), for me pulse basically works 99.9% of the time.
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.
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.
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.
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.
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.
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.
>If PA isn't doing it, your apps will be instead.
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).
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).
But don't some card have hardware resampling? Seems my sound blaster audigy from the early 2000's advertised something like that. If resampling is such a hog, why can't the sound card do it? Seems like thats the whole point?
Yes. No computers ship with them, and haven't since the 90s. They are a super niche product.
> 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.
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.
This is good info but here is the thing. On my minimum base install of debian stable with only a couple of the kde packages, I don't actually have any sound related packages installed:
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.
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.
So I did some research. I noticed some people speaking of DMIX in alsa for doing software mixing. One can install some plugin packages to enable a configurable resampler (libasound2-plugins on debian). You can then set /etc/asound.conf with some thing like:
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...
[2]https://hydrogenaud.io/index.php/topic,9772.0.html
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...
[2]https://hydrogenaud.io/index.php/topic,9772.0.html
> 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.
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.
> For a typical user - PulseAudio "just works" and there's no more to it than that
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...
[2] https://www.linuxmusicians.com/viewtopic.php?t=13979
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...
[2] https://www.linuxmusicians.com/viewtopic.php?t=13979
This is where using Debian Stable will bite you. The issue has been fixed 2 PulseAudio releases back.
[deleted]
I have flat out never seen it work on my systems, and that ain't for lack of trying. I dread when somebody suggests using it to solve a problem because it is a "now you have two problems" solution.
Tried recently? I'm certain if there were these major "show-stopping" issues, at least a few of the big distros would have noticed by now.
I might try it out again. On paper PA sounds cool, but as a power user, when I look at what processes are running on my machine, I don't like seeing any more than I have to. From my simple perspective (as a debian user), everything on my laptop works fine sound-wise. Then I want to be "cool" and use the latest and greatest, so I install (what I think to be) all the needed PA packages and reboot my machine. I notice nothing different other than now I have a background process that consumes CPU resources when ever a sound is playing. I don't like that, and it seems strange.
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?
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?
> "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.
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.
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.
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.
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!
...phew!
How is sound handled on FreeBSD? Or is FreeBSD going to be required to port and ship PulseAudio?
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.
> things like in-driver mixing that Linux drivers under Alsa even lack.
Uh?
Uh?
FreeBSD's sound drivers include software mixing, so that if there are multiple things that want to use a sound card, they don't block each other. Alsa's sound channels are blocking, which means that only one program at a time can use the sound device, which is what causes the entire tower atop it to form.
Nope, Alsa has offered dmix for years now.
Which is not done in the ALSA driver, but the ALSA user-space library. In contrast to that FreeBSD's OSS drivers do the mixing in kernel-space.
BSDs still use OSS, afaik. Linux replaced OSS with Alsa over licensing issues.
> 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.
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.
[deleted]
In one word: NUTS.
Isnt PulseAudio Part of systemd anyway nowadays? SCNR ;-)
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.