Another Slackware user with PulseAudio problems
 

Already looked at some similar PulseAudio threads, but probably have not found everything yet.

My observations:
PulseAudio tries to totally take over all sound (by indirection the ConsoleKit is taking over all sound). It has many interfaces for intercepting sound meant for other drivers. It does not seem to have any provision for cooperating nicely with other drivers.
These are the conclusions that I have come to after fighting with it for several weeks.

I have no interest at all in how some other users may have such a limited usage of sound that PulseAudio is perfectly fine for them. Those people should go away right now.

I want to use Jack.

I need to use SDL, as I am developing SDL software.
PulseAudio is blocking my SDL output. If I kill the pulseaudio task the SDL sound gets through.

Question 1: PulseAudio wants the audio group all to itself. Any evidence that this is necessary.

Question 2: I am getting two pulseaudio tasks. The PulseAudio docs seem to claim that starting extra pulseaudio, like one per user, is a good thing.
What I see is that the first pulseaudio uses up the CPU time, but produces no sound. How many pulseaudio is normal, how many is workable.

Question 3: My pulseaudio volume control only shows the dummy output. I have no idea which pulseaudio task it is referencing, or why pulseaudio is having trouble.

Question 4: I can use a TiMidity executable from my Linux 2.6, that works perfectly fine, even when PulseAudio is blocking all the other sound. It goes directly to ALSA port. But the TiMidity compiled on Linux 4.4.14 sounds like it is synthesizing at 4KHz. Is the latest TiMidity output going through
PulseAudio even when I tell it an ALSA port?

Question 5: Does PulseAudio corrupt sound, like resampling it at 4Kz, when it feels like it.
When playing TiMidity using aplaymidi, I get the sound going bad (sounds lik 4KHz), then good again, two or three times during the song (over 4 minutes).

Question 6: The bluetooth driver only interfaces with PulseAudio. Other programs will select the output sound device.

Question 7: I am going to put a sound device selection mechanism in my programs. How do I bypass PulseAudio and send sound directly to ALSA, from a program, and especially from a SDL program?
Without the user having to reconfigure anything?

Question 8: The PulseAudio volume control is dumbed down, inadequate, incomplete. Any alternatives, like using ALSA-mixer.

I'm one of those that has limited usage of sound. So, I don't have a whole lot of experience with configuring pulseaudio. On my HTPC and my desktop, sound just worked without any configuration out of the box. I haven't found any programs that don't work that way, although, I've never dug into them enough to know if I have SDL-based audio output (I imagine I do, since I have built SDL2_mixer for something).

However, the first question to ask is have you gotten rid of your previous audio configuration files like /etc/asound.conf and ~/.asoundrc (or at least moved them so they aren't being referenced)? They were likely designed with alsa in mind and generally don't work with pulseaudio (at least not without heavy modification). A good chunk of pulseaudio issues we see in the forum is due to these configuration files wreaking havoc. I just wanted to get that question out of the way...

The next question is to make sure you do not have /etc/rc.d/rc.pulseaudio as executable. For the majority of users, there's no reason to have that executable.

As to your questions, unfortunately, I can't answer most of your "questions" (they aren't all questions). But, I think the answer to "question" #6 is the whole reason we have pulseaudio in the first place. BlueZ removed alsa support in v5, and that is what prompted Pat to switch to pulseaudio. The below is from the 14.2 changelog:

This is likely the reason you're not able to choose alsa for bluetooth audio... because BlueZ no longer supports it.

Insure that /etc/rc.d/{rc.alsa,rc.alsa-oss,rc.pulseaudio} be all 0644. And yes, a pulseaudio daemon is started when you log in as regular user. At least that's what most of us do and are happy with, maybe with simpler or easier to deal with use cases though.

Other than that, If you find something weird or wrong with pulseaudio, I suggest that you file an issue or several issues upstream, to get a chance they be worked on.

There's no evidence that this is true. If you set an application to send sound directly to ALSA, it bypasses Pulse and plays. So Pulse does not "own" the audio group. Also, I'm not clear on how Pulse "wants" the audio group all to itself? that's not how UNIX groups work.


I have no useful data for you, so I'll skip this one.

In which tab? Configuration? Input? Output? or all of them?

It shouldn't be, although Pulse may be aware of it via the Pulse ALSA-plugin. That shouldn't affect it though.

How did you install TiMidity? A configuration option can define what system it supports, and when I last checked, Pulse wasn't listed as an option.

Bottom line: as far as I know, TiMidity should be unaffected by Pulse. The fact that it appears to be is odd. Maybe kill PulseAudio and test.


Does this happen even if you kill Pulse?

As others have pointed out, Bluez doesn't do ALSA any more.

Just don't code for Pulse. You don't *have* to hook into Pulse. XMMS doesn't have Pulse output, for example. Audacity and VLC have Pulse options, but retains hooks directly into ALSA. Pulse can still manage it, because there's an ALSA plugin for Pulse. Of course, if SDL was compiled with Pulse support, then you may need to distribute / bundle your own SDL builds along with the rest of your code, but ultimately it's down to the libraries you include and the code you write. If you're leaning on SDL to handle all that low-level stuff for you, then you'll get what they give you.

[/QUOTE]

Well, there's alsamixer :) and, I guess, JACK.

That really should have been your first paragraph.

The pulseaudio build configuration has an enable/disable-jack option (seems to be enabled by default). Presumably jack would need to be installed for this to be effective but since jack would not be installed when Pat builds pulseaudio, the stock pulseaudio would not support jack. Therefore you will likely need to rebuild pulseaudio yourself with jack already installed.

When that's done, google "pulseaudio jack" - there are heaps of reasonable looking howto's out there.

chris

firefox 52 requires pulseaudio. i'm so fed up. i wish pat would rebuild firefox with alsa support, this is still possible.

Pat has just pushed an update on -current that contains a rebuilt Firefox with ALSA support

Done:

Thank you. I did find the upgrade slack packages and have already installed them.
It sounds like anyone doing any music or audio work has to take an axe to PulseAudio, without actually removing the libraries. That is what I needed to know first, as every configure is going to see that the PulseAudio libraries are present. If they needed to be removed it has to be before compiling any packages. Removing them latter will cause all kinds of new problems.
I have about 100 packages I have downloaded (library trip, they have a fast internet connection).

Slackware 14.2 was installed on wiped bare directories, so there should be no left over configuration files. When through that hell with that on Linux 2.4 installation.
Will look for the /etc/asound.conf file though, thank you.

The Slack howto file I found on how to tame PulseAudio seems helpful, but I also need to know the current situation, and the other users perspective. After two weeks of fighting with it I found there are far too many variations of setups to do random testing.

I do not know what got compiled into that new TiMidity, that is the problem.
Comparing their sources with a diff just resulted in a huge file with lots of changes.

I am having the similar problems with compiling plib, it compiles with warnings and then fatal errors due to type conversion.

Too bad pulse can't be tied strictly to bluez and only loaded strictly by bluez usage in the rc script. That way it lives and dies with bluez only.

I have a VIA southbridge with AC97 as a sound device.
ALSA is listing it as a device properly.

But, using fuser, I can see that one of the pulseaudio (and it does not say which one) has the /dev/snd ports.

Pulseaudio does not list it as a card
> pacmd list-cards
says there are 0 cards

The syslog has this in it:
<code>
Mar 16 12:27:00 MySys pulseaudio[825]: [pulseaudio] module.c: Failed to load module "module-alsa-card" (argument: "device_id="1" name="1" card_name="alsa_card.1" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes card_properties="module-udev-detect.discovered=1""): initialization failed.
Mar 16 12:27:00 MySys pulseaudio[1171]: [pulseaudio] module-alsa-card.c: Failed to find a working profile.
Mar 16 12:27:00 MySys pulseaudio[1171]: [pulseaudio] module.c: Failed to load module "module-alsa-card" (argument: "device_id="1" name="1" card_name="alsa_card.1" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes card_properties="module-udev-detect.discovered=1""): initialization failed.
Mar 16 12:27:05 MySys pulseaudio[2037]: [pulseaudio] module-alsa-card.c: Failed to find a working profile.
Mar 16 12:27:05 MySys pulseaudio[2037]: [pulseaudio] module.c: Failed to load module "module-alsa-card" (argument: "device_id="1" name="1" card_name="alsa_card.1" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes card_properties="module-udev-detect.discovered=1""): initialization failed.
Mar 16 12:27:05 MySys pulseaudio[2037]: [pulseaudio] bluez5-util.c: GetManagedObjects() failed: org.freedesktop.DBus.Error.ServiceUnknown: The name org.bluez was not provided by any .service files
Mar 16 12:47:11 MySys pulseaudio[825]: [pulseaudio] module-alsa-card.c: Failed to find a working profile.
Mar 16 12:47:11 MySys pulseaudio[825]: [pulseaudio] module.c: Failed to load module "module-alsa-card" (argument: "device_id="1" name="1" card_name="alsa_card.1" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes card_properties="module-udev-detect.discovered=1""): initialization failed.
Mar 16 12:47:11 MySys pulseaudio[2037]: [pulseaudio] module-alsa-card.c: Failed to find a working profile.
Mar 16 12:47:11 MySys pulseaudio[2037]: [pulseaudio] module.c: Failed to load module "module-alsa-card" (argument: "device_id="1" name="1" card_name="alsa_card.1" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes card_properties="module-udev-detect.discovered=1""): initialization failed.
</code>

As far as I can tell the /usr/share/pulse files are there.
This was installed directly from Slackware 14.2 CDROM.

I have managed to disable bluetooth, to eliminate one error message.
I do not have any bluetooth hardware.

I have commented out the pulseaudio in the /etc/asound.conf file, so next time I boot
I should have normal ALSA sound, maybe. But that will still leave the pulseaudio only programs stuck, and alot of error messages piling up in my syslog.
I still need to find out what is wrong with pulseaudio.

I have been thinking of starting it in system mode so as limit it to one task.
The ArchLinux PulseAudio troubleshooting say that is possible, but it will defeat some
features of PulseAudio. So what features will it defeat, and do they matter that much ??

I have many consoles running for the same user. I suspect that pulseaudio
screws up during console switches. There are hints that it mutes or blocks sound of the first user, which is exactly not what I want to happen. It seems that they think that who ever has the console is supposed to OWN the sound device. To change this kind of behavior you are expected to learn the pulseaudio programming language they use in their files (I really cannot call them config files).


PulseAudio FAQ says that PulseAudio expects to have the audio group to itself.
I found this in the PulseAudio FAQ where it said to make sure to remove all users from the audio group, and that PulseAudio should be the only member of the audio group. Failure to do this will result in slow switches of some kind. Its on their website.


<Just don't code for Pulse.>
If my program sends sounds to ALSA and the usual /etc/asound.conf that PulseAudio installs is present, then it will redirect my sounds to pulseaudio.
It has been posted elsewhere (ArchLinux) that two lines in the /etc/asound.conf
have be commented out to get ALSA working again. My program cannot change a users /etc config files, and requiring that those lines be changed would certainly be a massive alteration of all of a users sound setup.

I suspect that is happening to TiMidity, but I do not know what each of these cryptic config settings actually does.

I am a little surprised that no one could tell me how many pulseaudio should be running.
To count them try:
> ps -A | grep pulse
Also it would be helpful to know which is accumulating run time. On my system the first one accumulates the run time, and the second one (started by XFCE) has 0 run time.

Did you read /etc/pulse/default.pa to see what you can can comment out?

I have disabled the ALSA redirect to pulseaudio by commenting out the two lines in the /etc/asound.conf.

The alsamixer controls actively do useful things again.

I have been into the /etc/pulse files and disabled bluetooth. I read them all but there is not much else that is clear.

I have disabled the first pulseaudio by removing exec priv from /etc/rc.d/rc.pulseaudio.
The file said that it starts a system pulseaudio daemon.

XFCE is starting a pulseaudio, so there is one available, but it is not working.
Throws error messages about not being able to find ALSA profile, whatever that is.
I have checked that the /usr/share/pulse files are there.
Being that there was some sound previous (bad, but present), it must have been able to
find the files before. It may be the first pulseaudio was actually handling some sound
and the second started by XFCE cannot find the profile files.
I may be that Slackware is setup only for the system pulseaudio that is started by rc.d/rc.slackware, as Slackware installed that file as executable. The pulseaudio started by XFCE may be a rogue.

I wish someone with Slackware would tell me which pulseaudio they have running and which of these setups is supposed to work.


As of now, I can play midi using the latest TiMidity, without the noise problems it had before.
Part of that may have been priority issue, as it was set to a priority much higher than pulseaudio. If ALSA then redirected the output through pulseaudio, then the driver would be fighting for CPU with TiMidity. With only ALSA handling sound this does not happen.
Setting priority of TiMidity using the TiMidity start command line will always do this as it adds your number to a real-time priority that is much higher than anything else.
To set a lower priority in the rc.d/rc.local you must discover the TiMidity PID and then use system tools to set it directly. I set it to be close to the pulseaudio daemaon priority.

I can also use audacious, as it has an output selection that can select ALSA. Now that it does not redirect through pulseaudio it works and sounds great.

MPlayer sounds horrible and scratchy (same CD and songs as tested on Audacious). It also does not read the CDROM until the buffer is empty, and so the music stops every 10 sec to read more of the CDROM. Cannot find a setting to fix that or reason why there should be one.
KPlayer is a front for MPlayer and behaves exactly the same.

Amarok has gone amok. It was working last week, it would play its default music. Now it just flickers alot, with this little box that goes on and off about 3 to 4 times a second.
The little box has pause and cancel buttons, but you cannot hit them. Also Amarok is not responding so to even close it you must go through the "Program not responding" messages.

Still do not have sound for the Pairs program (which did have sound a couple weeks ago).

SDL sound still does not seem to work. This is in spite of it having worked after killing the pulseaudio daemon during a previous test.
I would be surprised if they managed to route it through pulseaudio, but not too surprised considering what a mess pulseaudio has caused.

I would not be too surprised if it turned out that some programs were using the system pulseaudio and some were using the XFCE pulseaudio. Then the two pulseaudio daemons were fighting to grab the sound devices, so only some programs would work depending on who had grabbed it.

On my HTPC (full Slackware64 14.2 install, no multilib), running KDE and kodi, I only have one pulseaudio process, and it is started by my user with a PPID of 1. The exact command is:

I do not have rc.pulseaudio or rc.alsa executable. I have no issues with my sound from kodi (using both passthrough and regular output for stereo or 5.1 surround sound).

While I can't comment on anything that you've manually switched to alsa, or anything that is having issues due to that switch, I can say that all those programs seem to work fine on my system (except I can't test the playing of CDs with mplayer as I removed my last CD/DVD drive from my desktop a year or so ago). But you seem to have a lot of problems that shouldn't exist with a relatively simple setup like yours. Have you tried reinstalling Slackware to see if those problems still occur?

Some things sound very weird here and definitely hint towards some issues specific to your system.

The pulseaudio init script by default is not used, you have to specifically enable it if you have a use case that needs it. Normal recommendation is to not use it.
I'm running KDE and have KDE starts pulseaudio, I have exactly one process running.

Are you starting timidity from an init script? If yes, you might have to change that to start timidity on login of your user instead.

I think that one way to suppress this stuff...
...would be to comment out... ...in /etc/pulse/default.pa

I haven't tried it on my systems, so I don't know what else will complain if you do it.

Have had some success, but not totally.

Discovered by pure desperation that pacmd has an "info" command that will dump who is connected to it.

I did not find this documented anywhere, not even in the PulseAudio man pages.
So if you are having problems too, write it down or memorize it.
Best way to examine PulseAudio
>> pacmd
>>> help
>>> info
>>> stat
>>> dump

Figured out something about the PulseAudio error messages. Guessing about this because they do not document any of this stuff.
** If you have a built-in sound device on your Motherboard, watch out **
** ALSA has detection that can find it.
** PulseAudio does NOT detect it, so no cards.
** To PulseAudio, ALSA is NOT A CARD, so it does not detect it using udev and does not detect anything using module-alsa-card either.
** You must manually load module-alsa-sink to get sound to go to ALSA NOT-A-CARD.
** After manual configuration, udev detect and many other modules are extraneous. They can be commented out to simplify things (optional).
** You will get the ALSA-sink as an output (but it is not a card).

This is likely a problem for anyone with an AC97 on their motherboard.
This setup is bad enough that there ought to be some menu selection in a setup tool to
select (real card, AC97, other on-board sound device, external device) etc.. and let the
tool set this mess up.

Can play music file using audacious (ALSA), and amarok (pulseaudio).
Amarok has settled down now that there is no CD in the CDROM drive.
Still do not know what it was doing, but have found two songs from the CDROM that mysteriously appeared in my directory.
I can have dragonplayer play simultaneous with audacious playing different music.

The Pairs game has sound again. It still cannot pronounce half of the Linux names, gets stuck. Has a serious defect in its text to speech converter that fails with the shipped game sounds.


ALSA direct does sound better than through PulseAudio.
I can use audacious->ALSA to play a song at much higher volume with full richness than dragonplayer->PulseAudio.
For the same music, PulseAudio seems to clip when set over 110%, a level that is much quieter at the speakers than ALSA direct.

The fuser command does not seem to indicate ownership of the device.
> fuser -v /dev/snd/*
I have seen fuser list three users of one device at the same time. I think they are all mixing through ALSA though. TiMidity is one reported and I know that goes through ALSA.
Have not figured what fuser is actually indicating with that name, or how it gets it.
If it is just a search of what programs think they are outputting to that device (indirectly)
then its meaning is quite different that what I initially would have thought.


Slackware shipped an SDL library that is connecting to pulseaudio. That is why SDL sound was not working (because pulseaudio was not working).
I got sound effects from SDL now, but not SDL MIDI music.


** NO SDL MIDI **
I DO NOT have MIDI music for SDL. Whatever they did does not route MIDI to TiMidity anymore.
I have TiMidity working, I can play songs using aplaymidi, so that is not the problem.

Installing the SDL library for Linux 2.6 may be an answer. I will get better sound and less hassle getting it away from PulseAudio.


Thanks for the help. Will post more later if any more real revelations are discovered.

I don't wish to do anything even remotely like hijacking this thread but it seems OP would be just as happy as I would be to eliminate Pulseaudio altogether. Any benefits it may offer are either of no benefit to me or are not worth the tradeoffs. I have no Bluetooth gear nor do I intend to start. While there is now a version of Jack that will function with Puleaudio they've had to leave out function I prefer to keep and I NEED Jack or I'm back to regular dual-booting to Windows, something I have been happily free from for over 5 years.

I have tried recommended means of removing Pulseaudio but I get errors and erratic behaviour. Can anyone tell me what 14.2 Mutilib has that is currently dependent on Pulseaudio so I can either eliminate or reconfigure it/them and dump this POS.

I would imagine it would be the exact same programs that you have to do on the 64bit version. It would probably be easiest to use a 32bit VM and rebuild everything needed in there to remove pulseaudio, then you can take those rebuilt packages, match them up with the multilib ones that Eric provides, then run convertpkg-compat32 on those packages and install (or "upgradepkg --reinstall" if they're already installed) on your multilib system.

Then someone could take those packages and host them so people could use slackpkg+ to install a pulseaudio free system. If no one would be willing to host them, but someone else would be willing to do the work of building the packages, I could host them.

Seriously, can we stop with the name calling? It might be a "POS" to you, but for many it is a lifesaver (no, I'm not one of them... I'm in the camp that I don't really care, because it hasn't affected me other than slightly simplifying installation so I don't have to specify cards and devices). When we name call, it loses the professionalism I like to think this forum has. Why can't you simply say "get rid of it"?

By coincidence I've just noticed my sound gone, and no playback devices in kmix. I think it might have something to do with virtual machines I'm running, but I'm not sure. And I have all the time in the world to chase down this problem and fix it.

So much for pulseaudio multiplexing sound. It can't even handle the startup of a VM. I could be wrong, of course, but this is the first problem I've had with sound since I bought my microphone last year, when pulseaudio in its infinite wisdom decided my microphone was my new playback device.

pavucontrol

I just did what I used to do with Windows - restarted. Which makes me wonder why I ever dropped Windows and moved to what was supposed to be a superior alternative.

But this pavucontrol is new to me and might come in useful some time, so thanks.

Frankly, all of my systems are able to auto-detect my built-in sound cards and pulseaudio uses them just fine.

Thanks for your comments in the first paragraph. I will see if that can help me.

As for the second, can you not understand the need to communicate frustration and even anger for the strong-arm adoption imperative that, at least for some, creates so many more problems than it solves (and mostly to benefit crappy onboard sound, leaving those of us who spend for actual quality in audio, which matters so much to those of us that work in it) that it seems like a solution searching for a problem? Please tell me why it' a good thing to suppress one's honest opinion in some attempt at phony politeness that is far from truthful or accurate. I think OTOH it is important to communicate that some people in fact DO find it a POS. It has certainly cost me many hours of hair pulling nastiness, and for what?

Bottom line - I fully understand and agree with the availability of enough options to suit even the lowest common denominator. What I don't understand nor approve is exclusion where it becomes required to have it AND a huge mess to uninstall and switch. That does not seem at all like the Linux that won me over and kept me pleased for going on decades.

First time I hear about this, but also the first time someone actually bothered to research his problems, so thank you for that!
Would you mind adding a bit more info about your sound device so we can research a bit more based on that? lspci output should be fine.
dmesg output would also be nice so we can see what udev does on boot with the sound device. This is important because theoretically pulseaudio
should do the same.

I think the SDL library shipped with Slackware doesn't provide midi support. There were requests in the past to add fluidsynth and recompile SDL to add that functionality. Likely you'd have to do something similar.

pulseaudio is here to stay, it's not going anywhere. As a matter of fact integration will only get deeper from this point forward.

Making pulseaudio optional would've resulted in a situation that made nobody happy. People who hate it would still complain that it's there, and people who need it would complain that it's not the default. Both would've complained that things aren't working properly. Given the trend that pulseaudio was becoming more and more an integral part of that stack that multiple apps would require soon, paired with the fact that it actually worked flawlessly in our testing and that it was relatively easy to switch back from a pulseaudio default to an alsa default (which is not the same as removing pulseaudio), we picked the logical option.

Seriously though, this is not some proprietary shit. This is open source software built by a community that's accessible and trying to help. If this is such a big deal to you, why don't you spend some effort and figure out how to make it better? For example, the pulseaudio <-> jack integration is just waiting for someone to write a SlackBuild and submit it to SlackBuilds.org. I'm pretty sure you'd make a whole bunch of people happy with that.

SDL2 now goes into -Current

Yes, I do understand a need to vent frustration, but do you have to do that with name calling? Everything else in that post was venting your frustration, but you had to end it with calling it a POS. Everybody already knew you weren't happy with it based on the previous information on the post, but you had remained relatively professional through it... until the end. Can we just stop that? Why can't we just discuss the removal without losing professionalism?

It's easy to remove if you don't have KDE, just get rid of the libpulse package and see what breaks.
I think on my machine it was only mpg123 that depended on it, but I only install like 20% of the system libs and build custom XFCE on that.

The packages currently containing binaries or libraries that link to libpulse are as follows:

MPlayer, alsa-plugins, audacious-plugins, ffmpeg, gst-plugins-good0, gst-plugins-good, kde-runtime, kmix, libao, libcanberra, mpg123, pamixer, pavucontrol, phonon, pulseaudio (obviously), sox, xfce4-pulseaudio-plugin, and xine-lib.

Thank you, elcore, but I'm afraid I'm rather fond of KDE or more specifically several KDE apps which substantially "raises the price of poker" for me. I suspect that ppr_kut is quite accurate that it is not going away and will in all likelihood grow as a dependency, much to my chagrin. It's strength as a centralized manager is also it's weakness in that it is getting more difficult with time to simply assign a different manager, like the more limited ALSA, to specific apps, let alone remove it altogether.

Talking about professionalism:

Extreme sarcasm? Or...?

No wonder users vent.

I took his words at face value. Users who complain about problems without digging into causes or providing pertinent system details are extremely frustrating, whereas users who do due diligence can make the difference between a problem getting prioritized or moved to the bottom of the list.

ppr:kut's post came across to me as something like: "Yaay finally someone gives me something I can actually work with! I might be able to work on this problem now!"

My interpretation only; apologies in advance if I've totally misread the situation.

Do you have any reason other than projection to believe that @ppr:kut was sarcastic? I don't remember any of his/her posts being that way; perhaps you remember some where he/she was.

I was asking if the quote was sarcasm, why are you looking for something else? I'm not expected to believe that selfprogrammed is the only one that 'researches' his pulseaudio problems. I can fully believe this is a report he is interested in though? I sure hope has better attitude about other reports as a dev despite as the comment suggests.

If professionalism is important, it should be even more as a contributor.

A little bit of sarcasm (if that's what it was) is quite a bit different from calling something a POS...

OK I kept quiet after your 2nd post about how much you were offended by "POS" out of a desire to keep On Topic. However since you have chosen yet a 3rd admonishment then let me just say that in my world, professionalism != PC politeness, especially when the term "politeness" so loosely includes word choice. It cracks me up that some people are offended at (to keep it lighter) "garbage" but consider it perfectly elegant to say "gar BAGE' " as if even pretending it is some other language and culture makes it acceptable.

My insincere apologies that I was brought up to "cut to the chase" and look at the meaning, rather than the symbol, in the interest of unobfuscated accuracy and communication. My sincere empathy that anyone took it as "blunt force trauma" but I am singularly unconcerned with what I consider to be silly games, especially when those games are obstacles to solutions. Say what you mean and keep it direct to the point. That's how I roll. If that is irretrievably offensive to some high degree, I have no problem with being ignored by those who indulge in "tilting at windmills".

Thanks boss, I will look into it.

MPlayer, ffmpeg, mpg123, I recompile them to avoid dependency and also to support more formats.
alsa-plugins, libao, xine-lib, I have these installed, but apparently there was nothing wrong so I have not rebuilt them.

The rest of the listed packages is mostly KDE related and I don't use or install that anymore.
KDE4 is not modular enough, my experience is that entire kdebase breaks without libpulse and the only reason for that is because audio notifications are not a module.
QT devs wrote a blog recently about modules and the direction they will take, so I guess there's a chance for KDE to decouple some things in the future.

No sarcasm, but just to be more clear, I was talking about pulseaudio problems specifically not general problems. From my memory this was truely the first instance where a user with frustrating pulseaudio problems presented actionable intel on what's going on/wrong. It's perfectly possible that there were others that I didn't read or didn't remember reading. If so, mea culpa.

Pardon my ignorance, but if i understood correctly, pulseaudio is mandatory for bluez > 5 so that people can use their hearing aids and other bluetooth devices. Is that correct ?

Assuming that the https://github.com/Arkq/bluez-alsa project does not provide the necessary functionality and cannot be used to rid us of pulseaudio, can't the pulseaudio be linked only to the bluez stack and every other package that has optional pulseaudio support like kmix, ffmpeg and others that Patrick mentioned be compiled with "--disable-pulseaudio" or relevant flag ?

Since the pulseaudio daemon autostarts for every user when needed, wouldn't this scenario allow the bluetooth devices to work correctly and allow everyone else that doesn't have bluetooth devices not to install the pulseaudio package ?

This is definitely NOT my area of expertise, but I did come across this. https://wiki.archlinux.org/index.php...o_through_JACK
As I read it, would need to recompile pulseaudio with jack support. The Arch script may offer some ideas. https://git.archlinux.org/svntogit/p...ges/pulseaudio
The SlackBuild for jack2 appears to add the necessary dbus support. https://www.slackbuilds.org/reposito...2/audio/jack2/
For more on module-jackdbus-connect https://www.freedesktop.org/wiki/Sof...les/#index44h3
Of course, I am probably way off base.

I'm not sure you understand what political correctness is. Per Google:

In fact, I was not offended by the use of POS and I never said I was offended (reread my posts if you missed that) . Swear words don't bother me. But when they're used in a professional environment, it can be frowned upon. My desire to not see name calling in the main support forum for Slackware has nothing to do with political correctness. It has to do with how we, the users of Slackware, come across to people seeking support. Think if you were to go into the Apple Store or Best Buy's Geek Squad (or insert other location here) and you bring them a phone to fix, and they say something along the lines of, "Oh, you got this POS? What a hunk of junk." How would that come across to you? Do you think you'd be as likely to continue using them as a service?

Since we are pretty much the face of the majority of Slackware support to the internet, it would be nice to not detract from what we provide by calling things POS. You can certainly vent your dissatisfaction of a product without resorting to petty name calling (and as I said, the rest of your initial post did just that). There is no issue discussing the removal of software from Slackware, but let's just keep it at that. FreeSlack does a good job at that.

I'm sorry. I didn't intend for this to be such a big deal. That is why I kept my request short and sweet and at the end of a post where I tried to provide help.

Sorry to interject, but this is not a "professional environment". It's a Linux community forum, populated overwhelmingly by volunteers.

That's a very different scenario, users are not customers/consumers and those providing any help/responding to posts are not employees with customer services training.

No offense intended, but you may be nitpicking here - and referring to a piece of software as a "POS" is not name calling by anyone's definition - as that would usually mean targeting a person(s).

Most users/potential users are mature and level headed enough to be able to judge software on it's merits, usefulness and how well it fulfills their needs, not from some off the cuff comments and opinions being expressed on a forum.

:hattip:

Hell, I get freaking paid professional developers whose initial bug reports are pretty much "I tried to do X and it didn't work." No logs, no detailed description of what they were doing, and no indication of the versions of the code with which they are trying to "do X". Remember, these are people who manage to debug the stuff that they write.

So, yeah, I think in a public forum such as this, where the people asking for help might not have debugged a software problem in their entire life, that @ppr:kut so rarely gets enough detail about the problem without having to pull teeth that he might comment such as he did.

You, OTOH, appear to be letting your dislike of pulseaudio spill into your perception of others and their intentions.

I know it isn't professional like a formal store front, however, we are the defacto support forum for Slackware. When users need help, they turn here. What they see here is a reflection on Slackware, whether or not it is intended to be, or whether or not we are the official or unofficial support forum (Slackware.com doesn't list it as official, however, slackbook does... I'm not sure which is the case). Calling anything a POS should be avoided...

If it were one or two posts, that is easily disregarded, however, this, for a lack of a better word, name calling been used since pulseaudio made an appearance. When people run into problems with pulseaudio, searches could lead them to these threads and they could get a bad taste of the type of support we try and provide in this forum. Since pulseaudio integration is likely to just get deeper in Slackware, and people will no doubt want to remove it, we don't need to consistently call it a POS. We should be able to just calmly discuss what needs to be done to remove it. We can easily discuss the removal of KDE or XFCE without all the names, why can't we do it with pulseaudio as well?

I don't have any problems with people desiring to remove pulseaudio from their system. Slackware is quite versatile in allowing users to customize their systems. And as I said earlier, if no one else wants to, I'd be willing to host a slackpkg+ capable repo of the rebuilt packages needed to remove pulseaudio... I just won't do the work on rebuilding the packages myself since I wouldn't use them and it wouldn't be easy to test them.

I have no interest at all in how some other users may have such a limited usage of sound that PulseAudio is perfectly fine for them. Those people should go away right now.

Now it is the first paragraph. Dumping an irrelevant how it "works for me" is of no help to those who are having trouble with PulseAudio. If it is not the same hardware as I have, it is not relevant. As for all the other garbage going on in MY thread, go take it to another thread.

Someone is clicking on "Did you find this post helpful" for political reasons. I see it on little one liners that offer nothing except opinion. Apparently the reps are tainted by political supporters.

I am going to continue with what I have discovered. I want any further comments to be about configuration. If you feel the need to defend PulseAudio, please sit on your lips, fingers, or whatever.

I cannot think well of the PulseAudio development. Outright declaration that it is hostile takeover of the Linux sound system, with little consideration of how it breaks existing programs and working environments. That hostile attitude basically invited lots of angry users, so if you hear of any angry users on this thread, shut up about it. I am looking for ways to restore what worked before and make PulseAudio (where needed) get along in a secondary role. That is not an invitation to argue anything. If you want to comment on this or argue PulseAudio, start your own thread.

** SDL MIDI music
I have SDL MIDI music working again. Upon booting the next day, SDL could play MIDI music.
The SDL library IS still supporting MIDI. I tested it a second day too, just to make sure it was reliable, and it still works. There is probably a gotcha out there that blocks it, and I have yet to discover what it is.

** pavucontrol
This PulseAudio volume control is part of the problem. It leads you to believe that it is the volume control for the sound system, and it is not. It is only the PulseAudio mixer volume control (controls).

** ALSA mixer loading is disabled in the installation Slackware 14.2
You need to make executable the file /etc/rc.d/rc.alsa, so that the saved mixer settings will be restored upon boot. Otherwise the ALSA master volume control is initialized at about 30%.

** ALSA needs a default setting of the ALSA mixer controls.
To save the mixer settings.
> alsactl store

You can do this manually once, after setting up the controls using alsamixer.
You can have the mixer controls saved automatically on shutdown by putting it in
/etc/rc.d/rec.local_shutdown (or similar depending upon distribution). Previous versions used to have it there, enabled by an if detection of alsa.

** PulseAudio problems
The PulseAudio sound goes through both the ALSA pcm volume control and the ALSA master volume control. At least it does with my current setup, and I do not know what it does in other setups.
If either of these is set low (which they are by default), then PulseAudio volume control must set higher, which leads to that mixer clipping peaks. That is one thing that is making PulseAudio sound so bad.

PulseAudio goes through the ALSA master volume control, so any program that sets volume by changing the ALSA master volume control (like music players) is going to change the PulseAudio volume too, and without it showing on pavucontrol.

If PulseAudio was written to cooperate with the existing ALSA sound system, it would have brought the sound into ALSA somewhere independent of the other ALSA users. When PulseAudio outputs to ALSA, it ought to have its own volume control in the ALSA mixer. The same is likely true of JACK, esound, and other mixers.

If PulseAudio always goes through the ALSA mixer devices, even when it intercepts ALSA directed outputs from other programs, then it is always going to need the ALSA mixer controls set to 100%. I have seen at least one other help that mentioned setting ALSA mixer to 100%, so it is apparently necessary. This is then a failing of the Slackware 14.2 installation when it disabled setting the ALSA mixer controls.

Still need to figure out how to write my program to evade that forced redirection to PulseAudio in the asound.conf file.

I have posted everything I currently know about PulseAudio detection of AC97.

The output of "lspci -v" contains this:

00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
Subsystem: Chaintech Computer Co. Ltd VT8233/A/8235/8237 AC97 Audio Controller
Flags: medium devsel, IRQ 22
I/O ports at eb00 [size=256]
Capabilities: [c0] Power Management version 2
Kernel driver in use: snd_via82xx
Kernel modules: snd_via82xx

The output of " /proc/asound/cards" contains this:
0 [V8237 ]: VIA8237 - VIA 8237
VIA 8237 with VIA1617A at 0xeb00, irq 22
1 [UART ]: MPU-401 UART - MPU-401 UART
MPU-401 UART at 0x330, irq 10

dmesg did not have any lines that I could find.
If PulseAudio is limited to what udev detects, then it is not universal, and some users are going to need alternatives. Another case of we can automagically detect all your hardware, that does not detect all the hardware. Program long enough, and you learn that whenever "ALL HARDWARE" appears as a claim, a failure is soon to follow. The ability to select and configure alternatives (without spending 3 weeks researching) is necessary.

Goodbye! Have a nice life!

So you get butt-hurt because the OP has asked that those who don't want to post on-topic and would rather blather on about anything but the topic?

To the OP...go back to 14.1. It's the last Slackware to work properly with sound (ALSA). 14.2 and this pulse-audio abortion that escaped from the garbage can it was thrown in is seriously a bummer, thus I'm glad I kept my old 14.1 on a second hdd. I tried several times in other threads about this pulse thing to get alsa working again, but in the end there were always things screwing up elsewhere eventually and I'd end up re-installing 14.2. I hate to say it, but I fear there won't be a 14.3 (or whatever) on my system if it's got this pulse thing still. Best of luck to you in your endeavors though with this thing. I wish I was schooled in programming and such things to be able to get into the depth you have and try to help out somehow. Good to see you're not a quitter though.

So since your post illustrates the thing I mentioned in other threads, which is why I asked the question here, I'll explain to you. There seems to be a cycle of conflict (I'll refer now as the poettering trap), where people seem to label each other and focus on the labeling. In this case it is whether you are a pulseaudio hater or lover. Today, since pulseaudio is available as part of the distro, there has been growing attacks on people not using it, calling them out as "haters" or "dislikers" as you've done, with flimsy reasoning. I think this is a troubling trend, since many people here are using slackware for its flexibility, and are now getting castigated about for their setup choice. Just so you understand, I'll use whatever solution is the best solution for my application. This is not about hating.

Therefore, the matter is not about classifying professional, the words they chose, or bug report filing. It's about whether we can get to problem solving without labeling each other then focusing on that instead. So I asked for clarity; is it really that everyone else does not research their pulseaudio problem, or have other been solutions presented before now? Exaggeration, or...?

I'd hope that peoples suggestions stop being castigated.