Running PulseAudio as System-Wide Daemon

Starting with PulseAudio 0.9.3 the daemon can be run as a system-wide instance which than can be shared by multiple local users. We recommend running the PulseAudio daemon per-user, just like the traditional ESD sound daemon. In some situations however, such as embedded systems where no real notion of a user exists, it makes sense to use the system-wide mode.

Before you now go ahead and use it please read about what is wrong with system mode.

To run PulseAudio in system-wide mode, it should be started as root with the --system command line argument. You may want to write a systemd service for starting PulseAudio at boot (or an init script if you're not using systemd). (TODO: We should provide a ready-made systemd service file with PulseAudio. Patches welcome!)

Many distributions use systemd to start per-user instances of PulseAudio. When using the system mode, the PulseAudio user services need to be disabled in systemd:

sudo systemctl --global disable pulseaudio.service pulseaudio.socket

It's also advisable to set autospawn = no in /etc/pulse/client.conf. It's not strictly necessary, because even if autospawning is enabled, it won't happen when PulseAudio is running in the system mode. However, if the daemon stops for some reason, then autospawning will happen, and that may make debugging more difficult.

When PulseAudio starts in the system mode, it will change its user and group from root to pulse in order to not have too many privileges. The pulse user needs to be in the audio and bluetooth groups in order to be able to use ALSA and bluetooth devices.

All users that need access to PulseAudio have to be in the pulse-access group, even root. (TODO: We should probably allow root to access PulseAudio without being in the pulse-access group. Patches welcome!)

Running PulseAudio in system-wide mode has some limitations:

All users with access to the sound server cann kill/modify all sinks/sources and streams of all other connected clients
There is only a single namespace for cached sound samples, i.e. there can be only a single Gnome event sound profile active at the same time

It has some disadvantages:

Worse security, because the user can now command a server app running under another user name. He could even load/unload modules from that sound server
Settings like the stored volume levels managed by module-stream-restore are no longer per-user but system-wide

Read more about what is wrong with system mode.

If the system-wide mode is enabled it is advisable to disable module loading during runtime by passing --disallow-module-loading to the daemon, to inhibit the user from loading arbitrary modules with potentially vulnerable code into the daemon. However, this breaks bluetooth and USB sound card hotplugging. (TODO: These things don't really need to break, --disallow-module-loading shouldn't prevent internal module loading from happening. Patches welcome!) You might want to use --disallow-exit as well to prevent users from shutting down PulseAudio.