[pulseaudio-discuss] Accessing audio as root

[Lennart Poettering]

On Sat, 02.01.10 07:59, Tanu Kaskinen (tanuk at iki.fi) wrote:

> At boot
> -------
> 
> At boot time there isn't really anybody having a private session; the
> boot messages are public. Speakup should run as user "anybody" (that's
> just a placeholder), and this "anybody" user has his own pulseaudio
> daemon running. Then either gdm or a console login manager starts. In my
> opinion, they should also run as "anybody", but there are probably
> reasons why gdm runs as user "gdm". That's why I use "anybody" just as a
> placeholder - speakup may also have to use a custom user.
> 
> At login
> --------
> 
> After logging in, the current session has become private to the logged
> in user. The pulseaudio daemon that the login manager used releases the
> sound card, and a new pulseaudio daemon is launched for the user. Now
> speakup has to start to use the user's pulseaudio. This happens by
> starting a new speakup daemon instance as part of the user's session
> setup.
> 
> Regarding this handover, it may need more or less logic in speakup - I
> don't know how speakup works. If only one daemon can
> use /dev/speakup_soft at a time, the previous instance needs to use
> consolekit to know when to release the access to /dev/speakup_soft and
> acquire it again when its session becomes active. The pulseaudio daemon
> of the "anybody" user stays running, streams to the sound card are just
> suspended. Speakup should probably detect this and close the stream when
> the session is deactivated, because when the session is activated again,
> I suspect you don't want to continue speaking from where you left off.
> 
> Switching virtual terminals
> ---------------------------
> 
> Switching virtual terminals works similarly to the login case. The
> access to the sound card moves from one user to another (might be
> "anybody" - in theory it doesn't make any difference whether the
> terminals have someone actually logged in or if the terminal user is the
> "anybody" dummy user).
> 
> So that's how I see it should work. I'm not very confident when speaking
> about consolekit and boot/login processes, so I have to hope that the
> system I described isn't too different from how things work in reality.

I mostly agree, though here's another idea:

Instead of creating a pseudo-session for the "idle" case, and then
have access regulated via the usual udev/ck acl logic and have clean
handovers between the idle and the gdm session's PA instances and then
to the gnome session's PA an alternative could be to fix speakup to
simply watch CK and disable itself as long as long as somebody is
logged in.

Effectively this means that instead of running PA for the tts daemon
which then watches access on the audio device nodes, it would have to
watch CK and enable/disable itself as soon as somebody logs out or
logs in and could directly access the audio devices.

However, that has various disadvantages including broken Bluetooth
support and suchlike. So I would probably recommend going for the
"idle" solution, and I belive the CK folks should be involved in the
discussion.

With very minimal work it should be possible to patch udev-acl and
write an udev rule that assigns audio device access to a tts user as
long as no CK session is available. If we have that then half of the
problem should already be solved: the tts daemon could run its own PA
daemon and audio handover between that and gdm and gnomne should work
already. What is missing though is support for console logins, so that
tts support is not lost as soon as someone logs in on the console
itself and hence device access is taken away from the tts user. For
that it would probably be best to simply start another tts daemon as
long as the user is logged in.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4