So you know who the author is. He will never do that. He is famous of doing the contrary.

Lennart's last commit to pulseaudio was "Wed, 16 May 2012 01:06:17 +0200", according to the information in the git repo. He has long moved on to greener pastures, so get over this crap.

The people who are developing pulseaudio now showed in the past 4 years that they are very capable of doing that. And it's in part to those 4 years of maturation and stabilization that pulseaudio reached a point where including it in Slackware was feasible.

Don't expect pulseaudio to go anywhere. If anything, it will likely get even deeper integration with upcoming changes. IMHO, any effort in trying to remove it is wasted time. Time much better spent researching what's causing the problem in the first place. But that might just be me...

8 members found this post helpful.

Research this, then: I do not want it.

It seems in your suggestion to conduct research, you've completely missed that this thread is about how to remove it. It is not a discussion of how to make pulseaudio work. It is not about how to coexist with ALSA. It is about how to disable pulseaudio, and keep it from ever interfering.

You are wasting your time telling people to work for the pulseaudio project that do not want it at all. Besides, you are making this alot bigger deal about this than needed. Recompiling only takes a few minutes. Literally. How do you think ALSA had worked in the first place?

What pprkut suggested makes sense, since pulseaudio is now being included in Slackware and many more apps *might* be using it in the future, so disabling pulseaudio is not the solution for long term. It does work fine as intended.

If you use third party repository such as SBo, some of the packages that can be linked to pulseaudio will have pulseaudio capability enabled by default, so if you disable it, you might have to do extra work if you want to use scripts provided by SBo.

1 members found this post helpful.

No, what he is saying does not make sense. Pulseaudio is just one sound daemon, where there have been alot of sound daemons over the years that can coexist on the system. Just like KDE is just one desktop environment.

Honestly, you guys are sounding like you would argue that someone can't uninstall KDE from Slackware, just because more apps could be using it. But my response is, I'm not using KDE, so I uninstalled it. And besides QT works just fine for the vast majority of existing software, without KDE. Think QT==ALSA/driver here. I don't need KDE runtime libs just to get access to QT as I don't need pulseaudio to get access to an ALSA driver!

This is not a case where there can only be one of this type of program installed at once. After all, Pat was able to ship slackware with both mixing applications together. This isn't the first time he shipped multiple sound mixing/daemons on slackware either. Pulseaudio is probably the only one that I've seen so far that doesn't coexist nicely with other setups when it is supposed to be disabled. The issue is that pulseaudio will start even when you don't want it, and when doing that it affects my use of my system. This is by design, and I see no reason to ask them to change their design, because their design will likely need to fundamentally change.

Many programs are nicely designed to decide on runtime which sound daemon to use. Many applications work fine without recompile. Only a few need recompiled.

4 members found this post helpful.

Yeah let's all drop what we're doing and waste our time instead researching what the problem with pulseaudio is. Even though, after 4 years of "maturation and stabilization", pulseaudio "just works".

Except, of course, for those of us for whom it doesn't "just work".

Poettering quit working on pulseaudio in 2012 because he realised his work was not something that could be fixed. He'll end up doing the same with his current project, leaving the rest of us to fix his mess. Greener pastures indeed.

1 members found this post helpful.

Look, all I said was that *I* think it's a waste of time trying to rip it out. Disabling it should be good enough. We spent a good amount of time making sure of that before adding it. If it's not, we need to hear about it, otherwise we can't fix it. So far, all the reports we got were caused by misconfiguration or PEBKAC.

If you don't care and just want to spend the effort to rip it out, also in the future, go ahead, knock yourself out. I certainly won't stop you.

2 members found this post helpful.

Then you need to read posts #6 and #7 again. This is in essence what I've been saying, that it cannot be fully disabled. Try operating the system with pulseaudio disabled, but installed on the system. This is following #6 as suggested and the wiki page, which is what I question. Try running all applications in Slackware for sometime, minus the bluetooth stack. You'll find that the volumes and mute states across the devices are changed interactively. You'll also notice that the daemon is started anyway. There can be a number of reasons for both. But ultimately there is no way completely to tell applications to prefer ALSA first, and no way to stop pulseaudio from manipulating your system. This is why many are now coming out in the months and weeks later saying they are fed up and trying to figure out what to do. I've lived with it both on and "disabled" for a while. I didn't make up my mind by some preconceived notion.

3 members found this post helpful.

Thanks for the information! Hopefully his project has been restructured and he will never come back.

To me the horrible feature of pulseaudio is the per application mixer settings. However, I never considered to removed pulseaudio from my system. I just don't use it directly in my own programs, but use libao or jack.

You mean people who upgraded instead of doing a clean install, and forgot that they no longer needed the ~/.asoundrc files they'd been previously using?

That was the case for every "Pulseaudio isn't working for me" thread we've had in the last year.

1 members found this post helpful.

I always do a clean install.

So what was the problem?

And btw, it's still extremely easy to tell from the changelog which packages would need to be rebuilt if you really want a Pulseaudio-free system.

http://ftp.oregonstate.edu/pub/slack.../ChangeLog.txt

It never ceases to surprise me that none of the people whining about Pulseaudio have ever cared enough to rebuild those packages and share them.

2 members found this post helpful.

I had no sound in Firefox, and the volume control icon on the KDE panel did not control volume universally. Yes, they're probably ridiculously easy to solve, but I've been having so many more pressing issues to resolve with UEFI, GPT, Xen, KVM and GPU passthrough that audio, which has never given me problems till now, has been placed firmly at the bottom of the list.

It is extremely easy to rebuild the packages. I am personally not going to distribute them, because I do not want to be in the role of providing packages to others. And it is really not necessary since almost everyone is used to the concept of a slackbuild script. There are others that have said they were successful. By concluding a with a false stereotypical framing that is just about a bunch of people whining, that can't help themselves, and skewing the real truth, you are just fueling more hatred on this forum. You know that there have been people that have offered larger alternatives such as systemd, pam and got skewered with people pouring out saying, "what's wrong the base system?", when they were just asking how to implement the alternative, or were providing said alternative, and have to respond being called a whiner? Frankly, in this climate that is enough just to never bother being with a package provider.

lolwut?

I'm 100 percent sure that this has never happened. But do link to that thread if I'm wrong.