[pulseaudio-discuss] Failed to connect pulseaudio server using user account A, when pulseaudio server is launched by different user account B

Colin Guthrie gmane at colin.guthr.ie
Wed Nov 26 02:11:20 PST 2008

Chen, Hao H wrote:
> Thanks, Cloin.
> 1> >>> for a general desktop system, per-user daemons are recommeneded. 
> => I see. It seems PA daemon is not supposed to be used simultaneously. It's better to launch daemon for each user.

Indeed. In a normal desktop, the users are not using the machine at the 
same time. The two users are perhaps both logged in, but only one has 
the keyboard, mouse and screen rights at any one time. In this (most 
common) scenario, each user will have their own pulseaudio daemon 
running and via the guidance of console-kit, pulse will be able to tell 
which user is currently active and thus will allow that user to output 
sound. The inactive user will just have their sound effectively muted 
(the applications are none the wiser!)

> 2> >>>For totally separate users, yes, this is normal. If you start as your user and su to another user, if the X11 access is granted, then, as I describe above, you can piggy back on to that for other users without any problems.
> => you mean X11 PA plugin should have been installed? If not, I guess another user is no way to access PA server.

Yes, the module module-x11-publish should set up the necessary 
properties on the root window to allow this su'ing about stuff to work.

Other users can still access the PA server but it will require some 
mucking around with cookie files/variables and such to get working. It's 
certainly not seemless.

That said, a user can configure their PA daemon to allow network access 
which can be unauthenticated - e.g. open to everyone. This can be done 
via paprefs.

> 3> It's said that users in same group "pulse" or "pulsexxx" could share PA server, is that real? What's the usage of those pulse groups?

These are kind of old these days. They only apply to a system-wide 
daemon, and not a per-user daemon.

In system wide mode, pulse will use the membership of the pulse group to 
determine which users are and are not allow to connect and output sound.

Likewise, the pulsert group is also somewhat old. Membership of this 
group (in per-user mode) will allow realtime privileges but this job is 
now better handled by policykit which is a system designed to allow 
exactly this kind of privilege granting structure.




Colin Guthrie

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]

More information about the pulseaudio-discuss mailing list