[pulseaudio-tickets] [PulseAudio] #824: Multiple users.

[PulseAudio]

#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