5

I often have two KDE sessions running as two different users. When I switch between them (e.g. Ctrl+Alt+F8) music that is playing in one of the accounts is muted on the other account. The same happens when I switch to a virtual terminal (Ctrl+Alt+F1).

As far as I know this is on purpose and makes sense for multiple human users but is annoying in my setup.

How can I keep music hearable whenever I switch to another KDE session or a virtual terminal?

I am using KDE Neon 5 based on Ubuntu 16.04 LTS (Xenial Xerus) with KDE 5.36.0 and Pulseaudio 8.0.

3

Solution

  1. Add all users that should be able play back to the pulse-access group

    # adduser problemofficer pulse-access

  2. Create /etc/systemd/system/pulseaudio.service with the following content:

    [Service]
    Type=simple
    PIDFile=/var/run/pulse/pid
    ExecStart=/usr/bin/pulseaudio --daemonize=yes --system=yes --disallow-module-loading=yes --disallow-exit=yes
    
    [Install]
    WantedBy=multi-user.target
    
  3. Enable this new systemd service so that it is started on boot: # systemctl enable pulseaudio

  4. Be aware that this configuration is

    • less secure (e.g. other users can listen to your microphone)
    • sound output will not automatically switch to and from headphones anymore and
    • might prevent Bluetooth from working. Also see Caveat section below.
  5. Reboot

Cause

The reason why the sound turns of is that Pulseaudio is started on each login with this users privileges and the system¹ does not allow other users to listen on other users audio.

Solution Background

Pulseaudio

In order to solve this problem Pulseaudio must be started with root privileges so that it runs as a system wide daemon of which there is only for all users. Everyone will connect to this one instance and will be able to playback and listen to everything other users playback or record.

Pulseaudio will not actually run as root the whole time, but will drop those privileges and assume the user pulse.

From man pulseaudio

User pulse, group pulse: if PulseAudio is running as a system daemon (see --system above) and is started as root the daemon will drop privileges and become a normal user process using this user and group. If PulseAudio is running as a user daemon this user and group has no meaning.

Note that "user daemon" is not the same as "system deamon". The former is how Pulseaudio ran before, the latter is how it will run if the changes are applied.

In order to be able to connect to the Pulseaudio system service you need to be a member of the pulse-access group.

Again from man pulseaudio

Group pulse-access: if PulseAudio is running as a system daemon (see --system above) access is granted to members of this group when they connect via AF_UNIX sockets. If PulseAudio is running as a user daemon this group has no meaning.

Systemd Service

As a quick work around it would be possible to simply kill all "user daemon" instances of Pulseaudio and then run /usr/bin/pulseaudio --system=yes. This would start Pulseaudio without it becoming a daemon and in a more insecure way but might be useful for a quick proof-of-concept check.

To make this persistent and for the Pulseaudio daemon to start automatically on startup it needs to added as a systemd service. This is what the file /etc/systemd/system/pulseaudio.service is for.

Pulseaudio will not start a user daemon² when it already finds a system daemon, this is why this solution works.

Caveat

The official Pulseaudio documentation advices against using Pulseaudio as a system daemon. Some of the problems mentioned are:

  • ...one especially problematic thing from security point of view is module loading. Anyone who has access can load and unload modules. Module loading can be disabled, but then bluetooth and alsa hotplug functionality doesn't work...

(That means when you plug-in headphones the sound output does not automatically switch from speakers to headphones. The reverse is also true when you remove the headphones. Both have to be done manually.)

  • ...much higher memory usage and CPU load in system mode...

    (Personally I haven't noticed any change in load though.)

  • ...all users that have access to the server can sniff into each others audio streams, listen to their mikes, and so on...

  • ...you also lose a lot of further functionality, like the bridging to jack...

And possibly other things that I do not understand and therefore did not felt were worthwhile including here.

Note regarding thecarpy's answer: None of the steps described in his answer were necessary for this solution.

Ressources


¹ If someone can explain this in detail, I would be very thankful.

² Assumption [citation required]

1

From https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/213149:

This is a pulseaudio "feature".

Edit /etc/default/pulseaudio

Change PULSEAUDIO_SYSTEM_START=0 to PULSEAUDIO_SYSTEM_START=1

That way, pulseaudio is started in system mode.

From the /etc/default/pulseaudio file:

# Start the PulseAudio sound server in system mode.
# (enables the pulseaudio init script)
# System mode is not the recommended way to run PulseAudio as it has some
# limitations (such as no shared memory access) and could potentially allow
# users to disconnect or redirect each others audio streams. The
# recommend way to run PulseAudio is as a per-session daemon. For GNOME
# sessions you can install pulseaudio-esound-compat and GNOME will
# automatically start PulseAudio on login (if ESD is enabled in
# System->Preferences->Sound). For other sessions, you can simply start
# PulseAudio with "pulseaudio --daemonize".
# 0 = don't start, 1 = start

The easiest way to apply your change is ensure pulseaudio is started with the --daemonize option and restart the system.

Another option is to remove pulseaudio entirely and use alsa instead, my preferred option, personally ...

  • I have already tried this, but it did not solve the problem. What I don't understand is: Do I only need to change the file or also change some init script to manually start pulseaudio with --daemonize? What is the relation between changing the config file and starting pulseaudio as a daemon? – problemofficer Jul 29 '17 at 16:02
  • 1
    Changing the config file ensures that no session-pulseaudio's are allowed to start, afaik, that is what I would expect, sadly, pulseaudio and systemd violate so many design principles that I would not be surprised if it did not work that way. You have to start pulseaudio with --daemonize for this to work, check your pulseaudio startup script (if you have one). If you have systemd, that would be /etc/systemd/system/pulseaudio.service - you might have to create that file to start pulseaudio with the --daemonize option: patrakov.blogspot.fr/2011/01/writing-systemd-service-files.html – thecarpy Jul 30 '17 at 21:21
  • Also, if pulseaudio is already running and you do not have a pulseaudio startup script, you will have to remove them from all gnome-sessions ... This would be pulseaudio NOT behaving as I would expect ... – thecarpy Jul 30 '17 at 21:23
  • 1
    Thanks for the systemd file name hint and the link, this helped me create a script. – problemofficer Jul 31 '17 at 17:50
0

I am running Arch Linux with systemd and I had exactly the same problem. My goal was simply to switch to another user (by Ctrl-Alt-Fx or by means of the display manager) and to keep my sound running.

I finally got it to work without having to play with system mode (dangerous, unsupported) or PolicyKit (don't know anything about that).

Steps:

  1. Add the $USER whose PulseAudio should keep playing to the "audio" group: usermod -aG audio $USER
  2. Enable lingering for the user, so that PulseAudio starts without being logged in: loginctl enable-linger $USER

Should this work you can optionally share this user's PA to other users on the net by adding something to ~/.config/pulse/default.pa, for example:

load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.0.0/24

For the "client users" just add to ~/.config/pulse/client.conf:

default-server = 127.0.0.1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.