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.

1 members found this post helpful.

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.

1 members found this post helpful.

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.

4 members found this post helpful.

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.

1 members found this post helpful.

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

2 members found this post helpful.

Done:

2 members found this post helpful.

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.

4 members found this post helpful.

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.