[pulseaudio-discuss] Accessing audio as root

[Tanu Kaskinen]

pe, 2010-01-01 kello 23:13 -0500, Bill Cox kirjoitti:
> IMO, Halim's more important comment was that PulseAudio breaks
> accessibility.  Speakup is either the #1 or #2 most popular Linux
> accessibility program for the blind and visually impaired.  It starts
> at boot, as it should, so a blind person can hear what's going on.
> 
> Gdm kills PulseAudio when a user logs in.  Speakup runs forever, and
> it' PulseAudio process hangs around forever, locking up the sound
> card, so the user can't get any sound in Gnome.

If speakup's model is that the daemon runs forever, without changing the
user when sessions are switched, it's in conflict with the normal
pulseaudio model, ie. the currently active user owns the sound hardware.
If the two programs are to be used simultaneously, one of these two
models has to change. Pulseaudio's model can be changed by running it in
system wide mode. That's a viable solution, but not ideal for the known
reasons.

Another approach, which you seem to have started thinking about, is
modifying pulseaudio's normal operating model so that it's compatible
with speakup. This approach should be used if speakup's current model is
correct. Otherwise speakup should be modified. My personal opinion is
that speakup's model is not correct, but since I'm not going to do any
coding related to this anyway, my opinion is irrelevant. But here's how
I see speakup should work, judge for yourself if it makes any sense:

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.

-- 
Tanu Kaskinen