[pulseaudio-discuss] system wide daemon (war: Re: using pulseaudio with simultaneous playback from mutiple X sessions)

Martin Steigerwald Martin at lichtvoll.de
Thu Nov 10 05:14:54 PST 2011

Hi Colin, hi everyone else,

Colin, thank you very much for your detailed answers.

Am Mittwoch, 9. November 2011 schrieb Colin Guthrie:
> You have to run a system-wide daemon. It's not something we actively
> support because this use case is very much in the minority and it
> causes a lot of headaches and unnecessary overhead - one of the
> primary disadvantages is the inability to support ho tplugging
> properly (because any kind of system-wide process will totally ignore
> the users carefully configured seat configurations etc), causes
> obvious security problems relating to eavesdropping and also cannot
> use SHM memory and thus causes a lot more overhead when dealing with
> client-server communications - i.e. you need to copy the audio data
> over the wire.

Now I had it that without Pulseaudio and thus using dmix, I could indeed 
hear sound in both sessions simultaneously, but Amarok after each song 
Amarok goes on playing and I do not hear anything anymore. Then I have to 
switch sessions, press pause, press play again to hear something for the 
duration of another song. This has been no matter whether I use GStreamer, 
Xine or VLC as phonon backend. Maybe its some remmant of Pulseaudio 
configuration in Phonon that I would have to remove manually? This used to 
work, but I do not really want to dig into it as also the audio quality is 
hearable lower than with Pulseaudio. Audio quality is some thing that 
Pulseaudio seems to get right.

After quite some consideration I am now trying this system-wide approach 
as I thought it would be the easiest to setup, cause I really want to call 
it a day for now. It was more painful as I thought it would be.

With Debian Sid and pulseaudio 1.1-1 package I now have:

merkaba:/etc/default> grep "[A-Z]=" pulseaudio

The second one seems to be necessary in order to get the usb sound card to 
work. I do not understand why tough. Cause even when its necessary to load 
a module, its still a system event, I do not see how a user is involved 
here despite me plugging in the card - but the system would not be able to 
map this to a concrete Linux user account anyway. Anyway without it, the 
usb sound card did not appear in pavucontrol.

merkaba:/etc> getent group | grep pulse       

I think the last time I tried system mode I accidentally used pulse as 
group to add my users to. That may well explain why it didn´t work back 

And then since I saw a user wide pulseaudio spawned nonetheless sometimes:

merkaba:/etc> grep autospawn pulse/client.conf 
autospawn = no

Surprisingly when I do this, a user wide daemon is *always* autospawned. 
This does not match the option name. I will try this once again after 
sending out this mail, but I tried two times already. 

I also have no user client.conf:

merkaba:~> LANG=C ls -l /home/{martin,ms}/pulse/client.conf
ls: cannot access /home/martin/pulse/client.conf: No such file or directory
ls: cannot access /home/ms/pulse/client.conf: No such file or directory

Whats going on?

And then Pulseaudio almost mutes audio playback when starting the second 
session, KMix shows a low initial volume. But when I put the volume back 
up its not as load as before. That was with the USB soundcard. alsamixer 
-c1 still showed a volume of 50, although I dragged it up to 80/90 in KMix 
which pavucontrol reflected in its display.

So this still is far from what I had without any configuration before, 
except for the audio quality, which is better. But at least I can hear 
sound in both sessions now and Amarok keeps playing loudly after a song 

> So while conceptually it's easy to say "you should support it, it's
> easy" you end up having to build a whole security manager into PA
> itself rather than rely on underlying systems. If we were to ever do
> that we'd get an equally vocal group of people saying "why the hell
> are you building security policy into PA, that's totally not it's job
> you idiots".

Well for software to be used by users, I tend to believe that the use 
cases define the job of the software. And it seems that even here is some 
support for this use case.

If the underlying mechanisms do not have any means for (part-wise) session 
sharing, I think they do not cover at least some use cases. So I think 
this might be something to fix in the underlying mechanisms.

Like dmix, if its has inferior sound quality, IMHO should be fixed up in 
ALSA instead of replicating it in Pulseaudio.

For now I see several heavy duplications of functionality

- pulseaudio replaces parts of ALSA
- pulseaudio replaces parts of Phonon or the other way around as you may 
see it

and then there is gstreamer, vlc, xine.

From my point of view this already looks overengineerd without adding 
support for simultaneous playback in several sessions.

For me this doesn´t feel quite right and I think it would be a rather good 
idea, when members of the Linux audio stack community - yes I know, other 
operating systems are involved, too - meet together, define clear layers 
and then mixing is there, managing audio for applications is there, codecs 
are there and thats it.

> So I say this: If you want system-wide PA, use system-wide PA. We do
> not recommend it, but it doesn't mean we'll sneak into your house at
> night and kill your kittens. You have extra overhead which may affect
> latency in games or voip and you have to make sure your users are in
> the pulse-access group. You might have to tweak certain files to get
> bluetooth working, you may not be able to use certain funky features
> such as network support etc. (tho' it should still be possible to
> teach SSH how to deal with PA natively - either per-user or
> system-wide, just like it does with X11 but sadly I just don't see it
> happening anytime soon).

Well I now have a somewhat working setup again. It is - except sound 
quality, where it exceeds - not up to par with the previous out of box 
configuration that for some reason now even without pulseaudio did not work 

Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

More information about the pulseaudio-discuss mailing list