Yes, you can remove Pulseaudio (with caveats)
First, can we please refrain from turning this into a flame war like every other Pulseaudio thread on the internet? I've spent weeks studying Pulse and Alsa trying to sort out how to get my system set the way I want it. And I've lost some hope for humanity in the process because of all the rage around this topic.
I sorted this all out on my previous distro. So it only took a little time to put it into practice on this fresh install of 14.2. And I thought I would actually document what I did since there is very little such documentation to be found. Rather, what can be found is very fragmented and some of it is fairly dated. The first part is probably the easiest. You simply removepkg pulseaudio. That is the only way to really ensure it doesn't get reactivated by some program. This does leave some files and directories behind. You can probably leave those. I hunted them down and removed them. I then recompiled Alsa. I got all the various tarballs from the Alsa site and built each one, starting with alsa-lib. The amusing thing is that the '--disable-pulseaudio' option on the alsa-plugins build triggered an 'unrecognized option' error. So much for './configure --help'. Anyhow, you may not strictly need to recompile Alsa. But it seemed the prudent thing to do since I do not know what options were used to build it for Pulse. You may or may not need to recompile programs that relied on Pulse. I'm running Firefox in xfce right now and watching YouTube with perfect sound even though this is the exact Firefox that came off the install iso. Audacious is cranking out some Rev. Horton Heat off a CD without being rebuilt. It's likely that other applications will survive the change as well. However, and this is the big caveat, not everything will. Seems KDE has a hardcoded dependency on Pulse and will not start without it. I got stuck in the console on a reboot and had to figure out how to start an xfce session from there. I didn't realize KDE was my default desktop. I was expecting a session manager. Oops. The other significant caveat is that this isn't exactly just a matter of getting rid of Pulse and going on your merry way. Alsa needs some configuration to take over the lead role again. This is where the documentation gets problematic. There's a lot of information at this site and more here. I used that information and some other bits from around the 'net to piece together a couple files that work for me. /etc/asound.conf Code:
# ALSA system-wide config file Code:
pcm.dmixed { I'm mainly sharing this in the hopes that those of us who want an option can start building a cohesive knowledge base on the subject. |
Thanks for documenting this. There will always be people who prefer ALSA over PulseAudio for whatever reasons, and this will help them.
Why don't you create an account at http://docs.slackware.com/ and add your knowledge to that Wiki? There already is http://docs.slackware.com/howtos:mul...io_non-default but that was written from a different mind set. And http://docs.slackware.com/howtos:multimedia:pulseaudio of course. |
I would be glad to contribute. I'm not sure just how much knowledge I have though. If you have any suggestions I'd be glad to hear them. Especially since your blog was one of the sources I relied on for this.
|
Quote:
Some are specifically linked, and those are obvious. I think there could be an non-obvious (run-time loading). Quote:
Also, I don't use Audacious. Quote:
|
Quote:
Quote:
I don't know how other players will respond to this. Hence the caveat. I'm also keenly aware that removing packages can break seemingly unrelated things. I recently lost the entire xfce desktop from a box because I wanted to remove Thunar. That's why I mentioned what I am running and tested it a bit before posting. I want to give folks enough information so they can assess the risks for themselves. Quote:
|
You are on the right track.
Quote:
As far as thunar, yes, that one might be a bit integrated into XFCE for the desktop component. You would want to keep that. |
Code:
bash-4.3$ mplayer |
I believe removing PulseAudio will break bluetooth sound functionality, as bluez needs PA.
|
It should be possible to disable pulseaudio through configuration files without removing any packages (though I've yet to see a need to do so here). If you remove libpulse.so, you'll get breakage.
I think an ideal guide to removing pulseaudio from the signal path would use a configuration approach. It shouldn't be necessary to use the big hammer here. |
Quote:
Quote:
Regarding Mplayer; I started rebuilding it before I had to leave for work. I'll finish it in the morning when I get home. Since the configure script is designed to autodetect PA, ALSA, and even OSS I'm confident it will function as expected. Kudos to the Mplayer devs for upholding the spirit of FOSS. I'll likely be switching to Mplayer just for that. The whole reason I got into Linux in the first place was for the freedom to set my system up the way I want rather than the way some corporate committee thinks it should be. Sadly, I think that freedom will be just a memory within a few years. |
Quote:
This is, apparently, overkill. When JACK starts pulseaudio stops. (Or should...) |
Quote:
|
Quote:
I'd like to change gears slightly on this thread. Since I'm a natural-born tinkerer I'll gladly take on the role of testing what programs can, or can not, be compiled without PA. So if anybody wants to find out if their favorite player can survive on straight ALSA just post a request and I'll see what I can do. I've already removed almost every trace of PA from my system. That makes me an ideal candidate for the job. Alternatively, if you already have something running without PA feel free to add that info to the mix. |
Quote:
Also, my reason for wanting to do away with PA in the first place is not without merit. Probably everybody reading this has at some point removed a program they didn't need. And quite often, though certainly not always, that process involves tracking down all the various config files and whatnot. I genuinely do not understand why PA has become so sacred as to warrant being an exception to that practice. When I go to remove KDE this weekend I seriously doubt I will encounter the same resistance to the idea as is displayed towards the idea of removing PA. PA is just a program, no different from any other. I do not need PA to do anything that I do with my computer any more than I need KDE. So I plan to remove both. I will probably remove other programs as well, for exactly the same reason. This isn't a witch hunt. It's just a matter of me paring down my system to where I want it. Actually, it may be easier and cleaner to just reinstall and uncheck KDE during the setup. I haven't restored any data yet. Removing PA only takes a few minutes, so I can easily do that again. Plus that would give me the chance to see if the ALSA configs I copied over really do make any difference. |
Quote:
That being said, I have absolutely no problems with PA. I didn't really see much of a difference from alsa... If I wasn't aware it had been added, there wouldn't have been any obvious signs that it was. There might've been less configuration in the beginning with PA, since with alsa, I usually had to change the default device using the asound.conf, but it's been so long since I've done that, I don't remember. Overall, I do appreciate the thoughtful discussion here vs the way some of the other PA threads spiraled. I don't think it's bad to discuss removing items from Slackware if there's a reason for the user to do it (whether KDE, PA, or items with questionable licenses), just as I don't think it is bad to keep everything installed on Slackware. Hopefully this thread can lead to some thorough, up-to-date information that can be added to the wiki so it is easily referenceable. |
All times are GMT -5. The time now is 06:56 PM. |