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~/.asoundrcThe final caveat is that I make no promises those files will work for you. But I hope the links I provided will hold whatever information you may need to figure it out. Please don't ask me, I don't have any answers. I did this largely by trial and error. I'd try a config somebody recommended, find out it didn't work, and try another. I don't understand the format and options enough to parse what's actually going on. I'm reasonably sure the .asoundrc file is far more complicated than it needs to be. But I'm planning to experiment with that to see if I really can get surround sound out of it.

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:multimediaulseaudio of course.

3 members found this post helpful.

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.

You don't need to recompile those programs. You just need to remove the pulseaudio redirect in asound.conf. KEEP the file in /etc.

Some are specifically linked, and those are obvious. I think there could be an non-obvious (run-time loading).

I did not test this (no KDE here), but seems strange.

Also, I don't use Audacious.

You don't need anything in the file if you have a simple system configuration. I never created asound.conf in the past, and current keep an empty file due to pulseaudio. Some people need a bit in there. If it works for you great, and if you can explain a bit more, the better.

2 members found this post helpful.

I did keep the file where it was. Or do you mean the rc.pulse file hiding there? I didn't remove it yey.


I thought it was strange too. But it repeatedly erred out saying it couldn't find some .so related to pulse. Then it stopped X and left me in init 3.

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.


The asound.conf I posted is just a tweaked version of the original. I removed the redirection you mentioned above and made sure the info was right on the rest. I wish I could explain better. I read quite a lot on the subject but there is no documentation I could find that really explained the options in those files. I've seen configs that covered dozens of lines and configs like mine that only cover a few. Somehow, both work.

1 members found this post helpful.

You are on the right track.

Sounds like you do need to recompile a KDE component. The other thing I would suggest is to check/recompile MPlayer. I always recompile it, so my brain is a bit foggy there wrt pulseaudio.

As far as thunar, yes, that one might be a bit integrated into XFCE for the desktop component. You would want to keep that.

Folks might find that information useful.

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.

1 members found this post helpful.

Yes, Bluez relies on PA. I have no idea if there is a workaround for that. But I don't need Bluez. And I'm sure there are others that don't need it either. So this is an option for some. I also know from experience that removing Bluez can cause breakage. Or at least it triggers dependency warnings from a package manager.

I'm not putting this out there as the ultimate solution for everybody. I'm just experimenting to see what breaks and what the options are. So far, I'm content that I can get all the functionality that I want from my computer without leaving an unnecessary daemon lurking about. And I'm passing along that information in case others find it useful. I understand why PA has to be included, some folks need it. But I don't think that should mean that those of us who don't need it should be required to keep it- even in a dormant state. I think we live in strange times; it's easier and less controversial to switch C libraries or compilers than it is to change the audio stack.

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.

3 members found this post helpful.

That's what I did. (I do a lot of computer music, so pulseaudio is not recommended for the kind of work I do.) No problems so far. I did have some configuration issues with WINE applications, but it was largely due to my trying to compile WINE without any pulse support. When I did, sound didn't function well--even though I'm not using pulse. When I compiled WINE as default, things were fine.

This is, apparently, overkill. When JACK starts pulseaudio stops. (Or should...)

2 members found this post helpful.

put it on a notebook, start watch a film, plugin a HDMI cable to a TV or some Monitor with sound, get the audio output onto the hdmi device, on the fly. You mean this is not a functionality you want from your computer?

I believe the documentation on the JACK site shows how you can run JACK without even disabling PA. But I could be mistaken. I've read so much lately that it all blurs together. I've tried unsuccessfully to add JACK to my system so I could experiment with it as well.

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.

No, it isn't. But I understand that is essential to some people. The purpose of this thread is not to convince anybody to get rid of PA. I started this thread just to clear up some of the FUD surrounding the issue. Those who want/need PA are perfectly welcome to keep it. Just like those who want Emacs can keep it or those who want Vim can keep it. Their decision to keep those does not in any way invalidate my decision to use Geany instead. My sole motivation here is to document that PA can be removed without causing your computer to explode and to show what the tradeoffs might be so people can judge for themselves whether they need PA.

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.

1 members found this post helpful.

My computers never have their audio outputs adjusted. My desktop upstairs uses analog out to the speakers and my htpc downstairs uses an hdmi out to the stereo receiver. My netbook has remained on Windows for various reasons (I do love the addition of bash to Windows 10... it makes it so much easier to do certain tasks on my laptop). But, even if I had Slackware on my laptop, I never hook it up to hdmi, so it would only use the speakers out... I don't even use headphones.

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.