#824: Multiple users.
----------------------+-----------------------------------------------------
Reporter: olek | Owner: lennart
Type: defect | Status: closed
Milestone: | Component: daemon
Resolution: wontfix | Keywords:
----------------------+-----------------------------------------------------
Changes (by coling):
* status: new => closed
* resolution: => wontfix
Comment:
This is actually the expected behaviour.
It is not technically PulseAudio who imposes this, but lower parts of the
system, namely Console Kit and udev. Ultimately if your session is not
active (ck-list-sessions), then CK+udev ensures that your user does not
have write permission on the device nodes in /dev/snd/* by virtue of
editing and removing user-specific ACLs on those nodes.
PulseAudio simply checks to see that your user is permitted to access
those device nodes and if you do not, it ensures that all current (and any
future) streams are "corked" (a term meaning 'forcibly paused').
So really all we are doing is behaving like a good citizen based on what
the underlying systems impose upon us.
If you are one of the few users who actually want to allow a user with a
locked screen to play their Brittany Spears disog on loop at max volume,
then you have a couple of options, although they are not officially
supported.
You can either
a) Add your users to the 'audio' group. This requires that your hardware
supports hardware mixing, so is generally not a useful option as most h/w
does not support this.
or
b) Setup pulseaudio in system-wide mode. This is pretty evil from a
security stand point (other users can eavesdrop on your voip conversations
and other such like nasties) plus lots of efficiency savings are lost (no
SHM for app->PA data transfers means the requirement for memcpy). Also
there is the overhead of running PA as a system service and adding all the
users you want to allow access to it to the pulse-access group. While we
don't intentionally break it, system-wide mode is not really officially
supported.
So all in all, this is not really the designed use-case, but the
underlying principles are really lower down in the system and not
something we can work around without fundamental rethink of both PA design
and many of the underlying systems and permission models of Linux
userspace itself.
Just FYI, PulseAudio client applications can use a 'cork notification' to
pause themselves and thus present their GUI more gracefully when the users
session is reactivated. (FWIW this is very similar to what happens on OSX
too. i.e. compare what happens when using OSX and you do a "fast user
switch" while iTunes is playing, it will pause itself - however, if you
run VLC on OSX and switch away, VLC will be corked but will carry on where
it left off when you return without any manual unpausing as is needed in
iTunes - i.e. it does not support nice feedback and is forcibly corked).
--
Ticket URL: <http://pulseaudio.org/ticket/824#comment:2>
PulseAudio <http://pulseaudio.org/>
The PulseAudio Sound Server
_______________________________________________
pulseaudio-tickets mailing list
pulseaudio-tickets@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-tickets
