[pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions

[Colin Guthrie]

'Twas brillig, and Ben Bucksch at 07/11/11 19:43 did gyre and gimble:
> On 07.11.2011 19:59, Maarten Bosmans wrote:
>> I would load module-protocol-native-tcp with ip-acl=127.0.0.1.
>> Then for other users set PULSE_SERVER=localhost.
> 
> Yes, that's what I recommended a friend, too.
> Problem is: which pulse server is the main one and which one connects?
> Any user can log in first.
> 
> Also, what do you do in cases of e.g. mpd running as daemon (by design)
> and needing to output sound, and GNOME running on the same machine. Note
> that a lot of pulseaudio depends on an active X11 session, including the
> dbus stuff, and bails if there isn't.
> 
> Also note that many of the official disclaimers / stated problems of the
> system-wide solution apply when you enable a network port and do stuff
> as you suggest.
> 
> May I recommend to officially support the system-wide solution and make
> it work well? I don't see another solution for multi-user systems and
> daemons.

The term "multi-user systems" here is misleading. PA goes out of it's
way to be multi-user friendly. What it does not do particularly well
OOTB is multiple users at the same time, which, as stated, is by design.

I do not want user A to login and play their Brittany Spears discog and
lock their station meaning that I have to turn off all sound. I do not
want user A to lock their station while running a program that would let
them eavesdrop on my private VoIP calls.


Now keep in mind that this method of working is NOT really a PA design
anyway - yes the PA design fits in with this, but its the underlying
layers of the system that set the permissions in the first place.
Whether it's console-kit (rapidly becoming obsolete, but in use
currently) or systemd-logind, both ultimately work with udev to ensure
the ACLs for only the appropriate (i.e. active) user are written to the
audio device nodes. The fact that Linux does not have a revoke() system
to pull device access away from people meant that if a user had the
audio device open when his privileges were revoked, he could still
output sound. That's a bad situation but PA fixes that by noticing the
permission changes and being a good citizen. But once closed, the user
who has no writes on the device should not be able to play. Plain and
simple, that's what the lower level permission system imposes.


Now another thing that also works very well in the multi-user domain is
mutli-seat systems. If you have systems where two people can login at
the same time with separate keyboards, pointers and screens, then
systemd is very capable of defining seats and allocating e.g. PCI
devices or USB ports to each seat. PA will honour this and give each
user access to his own USB or PCI sound card. While the practicalities
are different, you cannot share single screen for graphics in this case,
and sound is pretty much in the same boat.

>> This recording thing is, among other things, one of the reasons
>> multiple users aren't allowed to connect to eachothers pulse daemon by
>> default.
> 
> Exactly. But Martin and me now stated a few usecases where this is
> *needed*. Saying "it's not recommended" and "yes, we know it's insecure"
> doesn't solve the actual problem. If that's the result of the design,
> then the design is obviously wrong and needs to be revised.

Needed use cases are still possible. You have to do more work yourself.
Depending on how distros package things, you may or may not have to do
much more then tick a box in a GUI, but that is very much beyond our
control.

You have to run a system-wide daemon. It's not something we actively
support because this use case is very much in the minority and it causes
a lot of headaches and unnecessary overhead - one of the primary
disadvantages is the inability to support ho tplugging properly (because
any kind of system-wide process will totally ignore the users carefully
configured seat configurations etc), causes obvious security problems
relating to eavesdropping and also cannot use SHM memory and thus causes
a lot more overhead when dealing with client-server communications -
i.e. you need to copy the audio data over the wire.


So while conceptually it's easy to say "you should support it, it's
easy" you end up having to build a whole security manager into PA itself
rather than rely on underlying systems. If we were to ever do that we'd
get an equally vocal group of people saying "why the hell are you
building security policy into PA, that's totally not it's job you idiots".


So I say this: If you want system-wide PA, use system-wide PA. We do not
recommend it, but it doesn't mean we'll sneak into your house at night
and kill your kittens. You have extra overhead which may affect latency
in games or voip and you have to make sure your users are in the
pulse-access group. You might have to tweak certain files to get
bluetooth working, you may not be able to use certain funky features
such as network support etc. (tho' it should still be possible to teach
SSH how to deal with PA natively - either per-user or system-wide, just
like it does with X11 but sadly I just don't see it happening anytime soon).

These are the trade offs and I don't think it's too much to ask.


Oh and for the MPD case I believe that issue is very similar to the
accessibility problem.

There are daemons which run accessibility systems to provide contextual
information to higher levels - such as scraping the console or reading
the screen. These run in the background on the system, in the same way
mpd runs.

Now the actual output stage for the audio from either of these systems
falls into two very broad categories: "system is idle waiting for
login", "user is logged in".

Now consider two users on an accessible system: One is visually impaired
the other is not (and this is a multi-user system where the users do not
log in at the same time). Obviously the visually impaired user will need
the system to work at the "idle/login screen" stage and I'm sure the
non-impaired user will accept this as a valid compromise (if not he's a
total dick!). But when the non-impaired user logs in, he doesn't want
the thing to tell him via the sound system what is on screen - he can
see that himself.

So my argument here is that it's NOT up to the underlying system (the
accessibility scraper or mpd) to decide when it should output the sound,
it's up to the user to decide. In the case of the login screen, this is
the system-administrators job to decide. Some GUI somewhere should ask:
Should the gdm user (or "login" user to be a little more generic) run
the process that connects to mpd and plays the sound back Y/N?

After that each user decides on their own whether or not to run that
process too.

This is an architectural change, but it allows the accessibility and mpd
type use cases and utilises the underlying security modules of the
system without baking anything specific into PA which, IMO is the
correct approach.




Now for the case of event sounds from non-active users I have a
different solution. If you are not the active user but are logged in on
the system, when you play an event sound (as signified in PA's
media.role property on streams, there could exist a PA module that
notifies the system dbus that such a notification wishes to be played.

The active user also have the same dbus module loaded which as well as
notifying out, also listens for other user notifications. In this case a
generic "other user event" sound could be played. It wouldn't be the
correct event sound but IMO this is actually desirable. You want to know
that the aural feedback you've just received is for someone else. And
that user should of course be able to disable such events.

This is a relatively easy system to cook up IMO - should only take a day
or so of hacking, although getting the design perfectly correct may be
interesting (as we'd really want to trigger a libcanbera event for the
"other user sound" event so really you'd want a dbus service on the
system bus and a little demon to run, per-user as the process that
listens for other user events - so not totally trivial)


Anyway, herein lies the end of my suggestions to solve the problems
experiences, not by letting all users have a free for all, but with
controlled means of access.

Hope you agree

Col









-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/