Pulseaudio for multiple users, without system-mode daemon

This post was written by eli on January 18, 2014
Posted Under: Linux,Linux sound

This is a simple and quick solution for those of us who want to run certain programs as a different user on the same desktop, for example running several user profiles of a browser at the same time. The main problem is usually that Pulseaudio doesn’t accept connections from a user other than the one logged in on the desktop.

It’s often suggested to go for a system mode Pulseaudio daemon, but judging from the developer’s own comments on this, and the friendly messages left in the system’s log when doing this, like

Jan 18 16:35:33 ocho pulseaudio[11158]: main.c: OK, so you are running PA in system mode. Please note that you most likely shouldn't be doing that.
Jan 18 16:35:33 ocho pulseaudio[11158]: main.c: If you do it nonetheless then it's your own fault if things don't work as expected.
Jan 18 16:35:33 ocho pulseaudio[11158]: main.c: Please read http://pulseaudio.org/wiki/WhatIsWrongWithSystemMode for an explanation why system mode is usually a bad idea.
Jan 18 16:35:33 ocho pulseaudio[11158]: module.c: module-hal-detect is deprecated: Please use module-udev-detect instead of module-hal-detect!
Jan 18 16:35:33 ocho pulseaudio[11158]: module-hal-detect-compat.c: We will now load module-udev-detect. Please make sure to remove module-hal-detect from your configuration

it’s probably not such a good idea. Plus that in my case, the sound card wasn’t detected in system wide mode, probably because some configuration issue, which I didn’t care much about working on. The bottom line is that the software’s authors don’t really want this to work.

Opening a TCP socket instead

The simple solution is given on this forum thread. This works well when there’s a specific user always logged on, and programs belonging to other dummy users are always run for specific purposes.

The idea behind this trick is to open a TCP port for native Pulseaudio communication, only it doesn’t require authentication, as long as the connection comes from 127.0.0.1, i.e. from the host itself. This opens the audio interface to any program running on the computer, including recording from the microphone. This makes no significant difference security-wise if the computer is accessed by a single user anyhow (possible spyware is likely to run with the logged in user ID anyhow, which has full access to audio either way).

This solution works on Fedora Core 12, but it’s probably the way to do it on any distribution released since 2009 or so.

Edit: It has been suggested in the comments below to use a UNIX socket instead of TCP. Haven’t tried it, but it seems like a better solution.

To do as the desktop’s user

So let’s get to the hands-on: First, copy /etc/pulse/default.pa into a file with the same name in the .pulse directory, that is

cp /etc/pulse/default.pa ~/.pulse/

And then edit the file, adding the following line at the end:

load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1

At this point, restart the pulseaudio deamon,

$ pulseaudio -k
$ pulseaudio -D

To do as the “fake” user

Now switch to the second user,  and create a file named client.conf under that user’s .pulse subdirectory

$ echo "default-server = 127.0.0.1" > ~/.pulse/client.conf

Note that default.pa and client.conf are in completely different directories, each belonging to a different user!

Surprisingly enough, that’s it. Any program running as the second user now has sound access.

Reader Comments

Hi Eli,

thank you very much for this post, works perfectly on Debian Wheezy :-)

#1 
Written By Matthias on April 1st, 2014 @ 16:58

do you think this will work better then what Valve is doing with SteamOS running Pulse in system wide mode in SteamOS?

#2 
Written By Cory on April 11th, 2014 @ 23:26

Actually, I suppose it will work slightly worse (with a negligible difference) because of the overhead of the TCP connection. I picked this solution to avoid tweaking my system too much.

#3 
Written By eli on April 12th, 2014 @ 07:05

Works perfectly with Debian Jessie (testing, in June 2014).
Thanks for the tip.

#4 
Written By captnfab on June 18th, 2014 @ 01:29

I found this post using a search engine and it worked perfectly for me on Kubuntu 14.04.1 (Ubuntu with KDE).
I run firefox as another less priviledged user and after
applying this configuration sound from firefox is working fine again. Thank you very much for publishing this.
Best regards, Peter.

#5 
Written By Peter Funk on August 15th, 2014 @ 17:59

You can also do this using a unix socket to avoid some overhead of TCP:

/etc/pulse/default.pa:
load-module module-native-protocol-unix auth-anonymous=1 socket=/tmp/my-pulse-socket-name

/etc/pulse/client.conf:
default-server = unix:/tmp/my-pulse-socket-name

#6 
Written By Anonymous on January 16th, 2015 @ 21:03

Dude,you are lifesaver! Thank you very much!

#7 
Written By Zer0 on March 21st, 2015 @ 15:42

Very nice, thanks

#8 
Written By marge on August 1st, 2015 @ 04:11

Wow! That was easy! I’ve been strugling with this problem for a while and I found this solution really clever!
Thank you very much!

#9 
Written By oldsphere on September 15th, 2015 @ 21:35

Great! Thank you!

#10 
Written By Oliver on December 5th, 2015 @ 15:51

Awesome, thanks. Works like a charm on UB 15.10

#11 
Written By Buzzz on December 9th, 2015 @ 17:54

Thanks for this tip, it works really nicely (also with unix sockets). Here is what I found in addition:

- On gentoo with pulseaudio 7.1 (and probably in many current distributions) the per-user config directory is ~/.config/pulse instead of ~/.pulse

- You do not have to copy /etc/pulse/default.pa, but can instead create ~/.config/pulse/default.pa starting with the following directive:

.include /etc/pulse/default.pa

- In order to avoid problems stop any programs that are running for the secondary user before restarting the pulseaudio daemon.

#12 
Written By canaaerus on January 1st, 2016 @ 13:42

Found this on a search. It works great and fixed an issue I was having. Thanks so much.

#13 
Written By ejones on May 1st, 2016 @ 19:18

Note that you can also set network access using paprefs (Debian package of same name). In paprefs, choose Network server => Enable network access to local sound devices & Don’t require authentication.
There’s no need to copy/edit default.pa or to create a client.conf for the secondary user(s).

Paprefs uses gconf and stores its config in ~/.gconf/system/pulseaudio/modules/remote-access/\%gconf.xml (you’d better remember this if you also use a default.pa and are wondering why something doesn’t work).

#14 
Written By Roel on June 9th, 2016 @ 18:43

Thanks for the socket tip, anonymous.
Easy and worked right of the bat!
I have a xrdp terminal running by my PC, and now both the PC and the terminal have audio coming out of the PC!

#15 
Written By Alroger Jr on July 8th, 2016 @ 19:25

Thanks, the solution before Pulseaudio 9.0 but does not anymore on ArchLinux :( May be due to some security changes in the new version.

#16 
Written By rob on September 3rd, 2016 @ 15:58

Thanks for writing up such a clear and straight forward solution. Thanks also to those that have posted comments that add further refinements such as using a UNIX socket.

I refined the solution to direct output from different users to different sinks, for example:

default-server = unix:/tmp/share-pulse
default-sink = alsa_output.usb-FiiO_DigiHug_USB_Audio-01.analog-stereo

The sink names can be obtained from the output of ‘pactl list’ when logged in as the server’s user.

#17 
Written By Michael H on October 16th, 2016 @ 00:13

The solution works perfectly, even to this day!
pulseaudio 10.0-2

#18 
Written By Mario on March 18th, 2017 @ 16:16

Hello. Used the UNIX socket variant by anonymous commenter with the .include by canaaerus. Works. Before that, used an even simpler trick which is to add a specific user to the audio group. That user, and only that user, can then use audio (including recording) at any time. This may be better security-wise than opening that users’ pulseaudio daemon to all other users. For example, user A is in group audio, user B is not. Programs running as user A can play music at any time. User B can join videoconference. When console switches to user A, user B’s videoconference should get isolated (no sound input or output). The solution explained on this page loses the nice isolation property.

#19 
Written By Stéphane Gourichon on May 31st, 2017 @ 09:29

Works perfectly for me ;-)

#20 
Written By Goths on June 11th, 2017 @ 14:23

Add a Comment

required, use real name
required, will not be published
optional, your blog address