Fair enough. My wording made me sound like "angry man", but what I'm trying to say is that audio in Linux right now is... problematic. We're not where I thought we'd be after twenty years. I don't have a problem with Slackware including pulseaudio. Pretty much had to do it.

Quick example... I have a netbook with 1 Gb RAM that I use as a practice amp (with jack). I also use it to pipe Spotify to my stereo amp using a cheap DAC. In those situations, pulseaudio solves nothing but adds latency and overhead that I just can't afford on that hardware. On that machine, I did uninstall pulseaudio and recompile a few packages.

On my desktop, I do use pulseaudio and I am working through problems.

PV already posted here listing the packages that need to be recompiled. It's not difficult, but I'm just not comfortable assisting someone to make changes that are that radical from the original system. If someone is uncomfortable making those changes, maybe they shouldn't be doing it.

2 members found this post helpful.

You're very welcome. Us Pulseaudio-refuseniks have to stick together, lest we get steamrollered by the "well, it works for me" brigade!


P.S.

I chose to bypass pulse after careful consideration and not as bass' put it, that I "don't want pulse just because of its original author or they feel the scope of the software doesn't match what they think it should match". The second part of that quote certainly does reflect my views (I think it's a bad design), but my choice is a practical one, not ideological:

I want to support multiple users on multiple consoles outputting sound at the same time. To do this with pulse you have to have each user running a pa daemon on top of an alsa dmix device (which is how I configured it) otherwise each daemon fights the other for access to the alsa device. But if you're going to do that, you might as well just bypass pulse altogether and use the alsa dmix directly, avoiding all the cpu overhead and cpu scheduling latency issues that multiple concurrent sound daemons bring. The alternative would be to run the pulseaudio daemon as root, but the pa devs themselves tell you not to do that.

I find it very frustrating when people just assume the reason someone has disabled pulse is out of ignorance or a kneejerk reaction; I spent a good few days just playing and learning the ins and outs of it. I even went as far as to learn about the pa api, so please don't be so dismissive of people when they choose not to run pulse, some folks may indeed be kneejerking, but not all of us.

2 members found this post helpful.

Agreed. To answer your puzzle as to why pulseEQ didn't work for me, it was because i could never get the pulse-dbus-module to launch and not fail.

1 members found this post helpful.

While your responses do have some validity let's look at the situation a little deeper. I dismissed the offered Jack solutions because afaik the version compatible with Pulse does not have all the features of the ALSA compatible version I need. Writing that off as "dismissive" is like saying a native of Siberia not buying a vehicle model that only comes without snow tires and for some design reason/flaw cannot be added aftermarket was merely "dismissive".

Part of what I both fail to understand and dislike about much of LP's "solutions" has to do with PID and permissions. If Pulse is supposed to be all User Only then why have anything in "/etc" at all? Why not have everything in $HOME ? FWIW I did learn from the responses here to make everything user level but was still unable to ever successfully launch the dbus module.

More importantly Pulse did NOT work right out of the box for me and if you take a look at my comparison list in a previous post it might be telling that the limited success with ALSA in 14.2 64bit is considered a success by me because it is better than it was with Pulse and vastly easier to control. That's how fail PA was for me.

I have already stated that I am not at all offended by Patrick's decision to switch to PA. He had no viable option to do otherwise. I even understand why the early instructions fro returning to ALSA were less easy and less effective and I'm OK with it... at least now that it is no longer a deal breaker for me.

Furthering the above analogy of vehicles in Siberia, I have to say that if "as intended" means I cant substitute snow tires for stock, that vehicle is unnecessarily (and stupidly) limited and I want no part of the concept, let alone the device.

I went into this fully prepared to learn to use and even like PA. It has improved but to me it is still a PITA... a lot of Cost with very little Benefit. By comparison, as limited as it is, I never had major problems with ALSA

1 members found this post helpful.

For The Record

I started this thread completely "on the fence", still happy with ALSA but realizing it has some serious flaws and that PA, or something like it, is The Future and rightly so. I freely admit that I dislike LP and his ways but that does not carry over into his finished products. Simply put, an individual may despise and be revolted by homosexuals but if they also think the Sistine Chapel murals are ugly, that individual is delusional And self-limiting.

I marked this thread as Solved because I now have a system with only minor issues in audio. I honestly don't care whether that was accomplished by ALSA or PA. It turned out that ALSA was simply the path of least resistance for me. It is my hope that despite being Solved for me, the thread continues to be productive for others whether they wish to eliminate PA altogether, create a blend as some have, or utilize PA only. All of those are valid and all of those still likely need some help because it is true that the Linux sound system is still something of a hodgepodge mess and it is also true, as Bassmadrigal pointed out, that PA is new to Slackware and not yet "muscle memory".

I suppose I didn't word my response well enough, but people like you weren't intended to be included. It was more towards the kneejerk reactions of "we have something from LP in Slackware... how do I get rid of it?" The part you quoted and bolded was intended to include people who are against pulse just because it is different from alsa, not because pulse can't do something they need that alsa could. I'm all for people who have done their research and decided to alter their system after that. This is no different than people who understand Slackware and choose to run a install other than full. If you make a choice, fully aware of the consequences (not necessarily bad consequences... maybe "results" would be a better term), then more power to you.

There weren't many (if any) success stories I remember reading when people were attempting to completely remove pulse... although, I could've seen them and forgotten. Maybe by the time he posted that list, the people who were shell-shocked by its inclusion mellowed down a bit and decided to keep it in there.

But I personally don't want to be the one to manage those packages, I'd just be willing to host it. I can barely keep my SlackBuilds up to date (and some may question how "up to date" they really are). I can't add this to my plate. I'd basically give someone the ability to upload the packages themselves, but I don't have the time to build them. I'd give them storage space and bandwidth. If my 100/100 home line gets saturated, I can upload them to my other host.

As for the comfortability... I imagine people who are opposed to PA would be a bit more on the technically minded side of users. And it was more because there were several packages that needed to be rebuilt. I think of it similar to Eric's compat32 packages. Sure, everyone who is running multilib should be able to download the 32bit packages and convert them themselves, but having a slackpkg+ capable repo would make things easier for those.

As it stands, I'm not pro-alsa and I'm not pro-pulseaudio... for the most part, both have been problem-free. I'd be fine with either being included in Slackware, but since pulse is default in 14.2, that's what I'm using on my 14.2 machines. My 14.1 machines are using alsa and will remain that way until they're updated to a Slackware that uses pulseaudio.

1 members found this post helpful.

Since when was it your job to police those motives and bring people back into line? Even if this were their reason for not wanting pulseaudio, why does it matter to you? People are perfectly entitled to repudiate software based on their own reasoning, and it's not actually your job to decide their reasoning is flawed.

2 members found this post helpful.

Pot. Meet Kettle! In all fairness though I have to wonder why "police" and "back into line", terms of coercion, were used to slam someone who offered and commonly offers help which is more than your little rant did. LTFU.

5 members found this post helpful.

Who says I am policing them? I am here on this forum to provide information and/or help. That may include questioning peoples' motives for what they're attempting. Sometimes they're trying to do something based on incorrect information, so it's best to clarify their intentions and reasons before proceeding. But if someone is wishing to continue (whether or not I think they should), I have no problems trying to help them through the process, although, I might mention a few warnings or caveats if applicable.

It is their computer, and they're obviously free to do what they want with it. But since I'm some random dude on the internet and not there with them. I try to find out all the information I feel is necessary so I can best help them through their problem.

A good example of this is the many posts in here requesting information on a minimal install. There is no ideal answer for a minimal install, so it is best to find out their reasons on why they want a minimal install. If it is just to make the system faster or ensure there's more memory available, then it is good to explain to them the reasons a minimal install likely wouldn't help with this. If they want to continue, I'm fine providing them resources to slim down their Slackware. Other people may come in asking for a minimal install for different reasons, like limited storage space on an embedded machine, headless server, etc. In those cases, the user has usually done enough research to understand some of the problems that can occur with a minimal install of Slackware, and we can continue from there.

If someone wants to remove pulseaudio just because it has LP's name on it, then they can still do that, but I'll probably let them know that LP hasn't been involved with it for years and that pulse does solve some problems that occur with alsa (mainly the difficulty in alsa if you need to switch between multiple outputs). If there's issues they're running into with pulse, personally, I'd try to see if they're willing to try and troubleshoot those rather than take the ax method and remove pulse (since pulse is likely to stay in Slackware and only get more and more difficult to remove as future versions of Slackware are released). But if they decide to just remove pulse, I'd be willing to help with what I can (although, my experience with removing pulse is only based on others' attempts to do it on the forum).

6 members found this post helpful.

Agreed. Bass' is one of the good guys here! Don't go making a drama out of this. He doesn't deserve that. I'm sorry I picked up on that quote now.

3 members found this post helpful.

Everybody take a deep breath. We may disagree sometimes and even get frustrated with each other, but we're all on the same team here.

I appreciate the offer, but my gut tells me not to do that. I don't think I've ever regretted following my instincts; not following them is a different story. It just feels wrong. I'd be encouraging people to intentionally break their system. It's different if I'm doing it for my own personal use, but at what point is it not even Slackware?

I'll be blunt about how I feel, but I was trying to get the OP's pulseaudio equalizer working. I wasn't encouraging anyone to rip out pulseaudio. I ignored all of the noise until after the thread was marked as solved.

Here's a quote from me back in 2006 that might lighten the mood and explain how I feel.

1 members found this post helpful.

There might be a slight misunderstanding here... I will likely not recommend that someone should remove pulseaudio to fix a problem. But if someone has already made that informed decision, then I'm fine helping them down that path. Just like if someone has decided they don't want any non-free software, I'd tell them about FreeSlack... but I'm not going to go and suggest FreeSlack to people who make no indication about caring about whether or not Slackware packages conform to GNU's "Free System Distribution Guidelines".

And no worries GazL. It's sometimes hard to get the full meaning of messages from text. I've made the mistake many times of thinking something I'd write would be taken as the sarcasm I thought was so obvious, but when I read it back after something blew up in my face, I realized that it wasn't so obvious. Now, I try to keep sarcasm out... unless it's associated with an emoticon to convey my meaning I've also been less than clear in other instances and had people misinterpret my messages (or maybe just my intentions behind those messages).

2 members found this post helpful.

I admire your philosophical ways.

Me? Misunderstand something? Ummm... yeah, probably. I thought you were offering to host packages if I supplied and managed them.

I don't want to do that. I'm actually not okay with me helping people down that path. That feels like the opposite of contributing to Slackware.

Anyway, one size does not fit all. I used Openbox, which made it a lot easier and made sense for a netbook. It meant I didn't have to deal with any KDE libraries that link to libpulse and how that might impact KDE.

And people have to know that bluetooth will be broken. Of course, I suppose someone could see if bluez-alsa is an option. Do you see where I'm going here? Pretty soon it's not even Slackware. No good can come from this.

Edit... I'll add one last thing. If anyone is dead set on doing this, I remember that I needed to find a patch to build gst-plugins-good0.

Not you, but anybody. I'm just willing to provide space if someone wants to come up with non-pulse packages

A lack of proper Bluetooth support would be one of the things I'd likely try to inform people of if I were to help them (unless one were to downgrade Bluez, but that could require other packages to be recompiled and/or downgraded).

I totally understand the rabbit hole that can come from trying to excise pulseaudio from Slackware. There will be a lot of changes and could lead to difficulties in ensuring Slackware is kept up-to-date with patches (since any patches that rely on pulse would also need to be recompiled without it). This is why I would encourage people to try and find solutions to their problems without removing pulse. It really is easier to keep stock packages stock.