Hi!
On Tue, Jun 07, 2016 at 04:10:29PM +0200, Istvan Gabor wrote:
...
>
> I frequently listen to music on the computer. When I switch user the
> sound for the first user turns off. How can I set pulseaudio to play
> desktop1 sound for other desktops?
>
> I would like to play the same music while switching between desktops.
>
Pulseaudio default mode of operation is a per-user model. That is,
the whole process dynamically starts as a user daemon, not as a system
one. This is why you'll get the following hierarchy in a typical setup:
$ systemd-cgls
Control group /:
-.slice
â??â??init.scope
â?? â??â??1 /sbin/init
â??â??system.slice
â?? â??
â?? ...
â??â??user.slice
â??â??user-1000.slice
â??â??user at 1000.service
â?? â??â??pulseaudio.service <== [ PA running under user instance ]
â?? â?? â??â??474 /usr/bin/pulseaudio --daemonize=no
â?? â?? â??â??492 /usr/lib/pulse/gconf-helper
â?? ...
â??â??session-c1.scope
If so, how such a user daemon access kernel devices under /dev/sound/*,
which are typically owned by root? Here comes the role of session
managers like systemd-logind and ConsoleKit (much earlier). Whenever
you login, systemd-logind through PAM knows that a new session was
created, and after knowing so directly adds ACL permissions [1] to the
sound device files so they can be accessible by your user processes.
These ACL permissions can be easily shown using:
$ getfacl /dev/snd/controlC0
user::rw-
user:darwish:rw- <== [ logind gave me access to sound devices ]
group::rw-
mask::rw-
other::---
Now if I switch the console, e.g. using Ctrl+Alt+F3, suddenly I don't
hear any sound. That's because logind detected the session switch
and revoked my earlier-granted access to the sound device. This can
be further evidenced by logging in that new terminal as root and doing:
# User 'darwish' no longer has any access to audio
$ getfacl /dev/snd/controlC0
user::rw-
group::rw-
mask::rw-
other::---
Meanwhile, if I switch back to the graphical session, I'll hear the
playback sound again. That's because permission to access the sound
devices has been _re-granted_ to my pulseaudio user daemon.
The pulse user daemon detects such granting and revocation of sound
device permissions through module-udev-detect, which internally uses
libudev device monitoring capabilities [2]. That's why when switching
sessions, e.g. from graphical to console, one gets the following
messages from pulse:
D: module-udev-detect.c: /dev/snd/controlC0 is accessible: no
D: module-udev-detect.c: Suspending all sinks and sources of card
alsa_card.pci-0000_00_14.2.
And no sound is further heard. And when returning back, pulse prints:
D: module-udev-detect.c: /dev/snd/controlC0 is accessible: yes
D: module-udev-detect.c: Resuming all sinks and sources of card
alsa_card.pci-0000_00_14.2.
And sound magically returns. This basically answers your first
question and explains why when you switched to a different user, the
sound from the first user went silent.
Now, if you want to play the same music while switching between
desktops, you have the option of running PulseAudio in "system mode".
In that mode, pulse starts as a regular system-wide daemon and becomes
quiet impartial to the concepts of sessions, session-switching, etc.
Here is a nice guide on the topic. [3]
Note though that due to how pulse was originally designed, running in
system mode implies that any user can snoop on other user's audio
contents, etc. Moreover, for legacy reasons, shared memory between the
client and server is disabled on system mode. That's usually only
problematic though only if you're having latency-sensitive audio; e.g.
fast-paced games.
Regards,
[1] https://wiki.archlinux.org/index.php/Access_Control_Lists
[2] "libudev Monitoring Interface", http://www.signal11.us/oss/udev/
[3] https://possiblelossofprecision.net/?p=1956
--
Darwish
http://darwish.chasingpointers.com
