pulse audio: multi-source playback no longer possible
 

Slackware 64 -current/14.2 (updated today).

If two programs attempt to play sound at the same time, one will freeze until the other stops playing. This used to work in the pure alsa setup.

Action taken: commented out entire contents of /etc/asound.conf file.

Result of action: Still no ability to play multiple sound sources at once.

Next action: search and destroy, a manual traversal of the / directory and all sub-directories, removing any file with "pulse" or "pa" in its file name or its contents.

I am deferring this action in the hopes that some kind person here could clue me into a better and less dangerous solution. ;) Thank you in advance.

Er, what?

Isn't this the problem that Pulseaudio was invented to solve?

I won't be able to check this myself for a little while, unfortunately.

pzognar,
If your goal is to disable pulseaudio (which may be your simplest course of action) maybe this post will help?

Take a look at http://alien.slackbook.org/blog/puls...-current-beta/, if you still want to fix it.

Probably, you need new .conf files.

I can't help more, as I use JACK and pulse is banished from my slackware.

I assume he means two programs from two different users, as otherwise the question doesn't make any sense (but see after-thought below).

When two individual per-user pulseaudio daemons try and use a 'sink' that refers to the same back-end alsa device concurrently one of them will block until the other suspends its use of the sink.


Using a system-wide pulseaudio rather than per-user will avoid the issue but is strongly discouraged by the pulseaudio devs. The other option is to configure pulseaudio to use a dmix device as the back-end for the sink, which will allow two different users to use the same pulseaudio sink concurrently. The arch wiki has some details on using dmix as a sink.

The problem with the dmix approach is you have additional overhead and you might very well be better off just disabling it and using old-school alsa directly. On this admittedly old box (a single-core, P4 2.66Ghz) each pulseaudio daemon will take 5-8% cpu depending on the complexity of the mixing/resampling it is having to do, so two separate users outputting via pulse will use somewhere around 10-15% cpu before you've even accounted for any cpu the actual media player you're using is taking. On a more modern and reasonably spec'd box this load will be less noticeable of course, but it does demonstrate that pulse is quite heavy (pavucontrol is also a horrible cpu hog, so I wouldn't leave that open!).


I do like the features pulseaudio brings, but I find this per-user server design architecturally suspect and I wish they'd put more effort into solving the issues with the system-wide approach rather than washing their hands of it and saying just use it per-user. Maybe it needed system-wide and per-user components, but I'm just bike-shedding now as I don't have enough understanding of its internals, or the reasons behind the design decisions made: I just hope it wasn't "because its easier".


After-thought: Any ALSA program that tries to open "front" or "surround" is also likely to grab the underlying alsa device and prevent pulse from using its sink. Make sure they only use the 'default' alsa device which is redirected through pulseaudio to avoid this problem.

I use pulse system-wide. To me it works better. Try using it system-wide and you can get multi-source audio working.

Heh, I solved it months ago in a pure Alsa system. Do you want my .asoundrc? ;)

No, two sources one user.

Let's get specific: run audacious. It's playing.

Type "play try.wav" (obvious replace try.wav with an audio file you have lying around).

Bam: play is frozen. Can't even control-c it. Fail.

Play is part of sox.

UPDATE

Not sure what combination of Things I Tried worked, but while audacious was playing, I was able to play a second audio file using aplay.

play (sox) still hangs.

mplayer plays. I don't normally use mplayer for plain audio files ... so maybe that worked all the time?

Ran xine: it froze. Had to kill -9 it. Then I got smart: ran xine with no parameters, so that it would not freeze. Went into its settings. Set the audio to output to alsa instead of pulse. Aha!

So looks like as a global problem, this is solved. It has become a per-program situation. Next up: make sox/play work. :p

Thank you, everyone, for all of your replies. :)

Good luck with sox, it probably is not pulse aware and uses ALSA directly (thus causing the trouble you are having).

Have you tried it with

And yet when I set xine to use alsa, it worked. And aplay, which is part of alsa, works.

sox/play will use the native pulse interface, as will ogg123, mpg123 and a number of the others. Some you may find need configuring.

In audacious go into output -> audio-settings and make sure you've set it to use the pulse plugin and not the alsa one, which it will use by default.

No thank you. ALSA has supported software mixing out of the box for a long time now. It's set up in /usr/share/alsa/alsa.conf. What I see too often is people breaking that by having their .asoundrc files in the wrong format.

Actually... you've removed that .asoundrc file now that you have Pulseaudio set up, right? If not, it's probably what's causing the problem.

Tried this here: While playing an OGG in audacious, open a terminal and play a different one with ogg123. Result: both play at the same time.

No extra configuration was required.