[pulseaudio-discuss] Accessing audio as root

[Colin Guthrie]

'Twas brillig, and Bill Cox at 02/01/10 22:37 did gyre and gimble:
> This scheme sounds reasonable, though whenever someone says
> "impossible", I'm naturally inclined to give it a solid try. 

Well of course it's not impossible, suitible changes all round could
enable it. I should really have said not sensible. It's definitely not
the approach I would take.

> Why
> would it be impossible to add PA hooks I could run when PA gains,
> uncorks, corks, or delets a connection to a card?  I thought I already
> saw a system of hooks being called. 

There is a perfectly good system of hooks etc. inside PA but it all
deals with scenarios *inside a given user session*. Once the user loses
control of the sound hardware you should really think of that users PA
process going to sleep and not doing anything useful until it gets its
access back again.

The whole problem you're trying to solve here is two fold: 1) when a
given user is not actually logged in yet and the system is idle/at gdm
login. and 2) When multiple users are logged in and we're switching
between logins.

In all cases I'm suggesting using a user account of some sort: e.g. the
users bill and colin for the real logins and the users gdm and idle for
the login screens. This is four potential users and four potential PA
daemons. Usign the hooks system to *kill* the speechd-up processes could
work, but it'll never allow it to *start* them unless PA is *already
running*. It is this last point that is the critical one. This is why
IMO it's essential to look at this from the CK side.

> I'm worried that if I follow the
> user instead using CK, and my logic for card access transfer does not
> match PA's, then I might transfer speach while PA does not transfer
> audio card access.

PA relies on CK to do it so if your CK hooks are not triggered, PA wont
be informed about this either and the ACLs wont be written to udev. It's
pretty safe IMO to rely on CK.

> We have to kill the user's speech-dispatcher and speechd-up deamons
> when access to a card is transfered to a new PA instance.

No you don't. PA doesn't die when the user no longer has access to a
card. Even without PA, all current alsa clients are not killed when the
ACLs are rewritten. PA allows the whole process to be handled
gracefully, but it doesn't die. Neither should speechd-up et. al. They
should just go "Oh, I'm no longer active. I'll give up control of the
/dev/softsynth node and wait until I'm active again" and then basically
idle until that time comes along. They could even spit out a "You user
session is active again" message when they get control back.

So the idea would be to start speechd-up whenever a user logs in for the
first time. It will stay running until that user logs out.

In the case of the gdm/idle users they are also started when the system
is in that state - allowing login prompts etc. to be spoken. Of course
these sessions may die off pretty quickly, but that's fine IMO.


> There can
> only be one speechd-up and one speech-dispatcher process at a time.

I think this is broken. There should be multiple processes possible, one
for each user (remember a user can login on both graphical display and
tty1) in much the same way as there is one PA process per user. Only one
of these processes will be active per-seat (a multi-seat system may have
a mix of blind and sighted users - if two blind users are logged in to
the same physical machine but at separate seats there will *need* to be
two speechd-up processes running.... I'm not sure how that would work if
there is only one /dev/softsynth system but it certainly demonstrates
the need for multiple dispatchers running).

> For one think, speechd-up locks the /dev/softsynth device, and the
> second speechd-up wont even run.  speech-dispatcher opens a port,
> which speechd-up uses for communication, and multiple
> speech-dispatchers conflict on the port.  But, it should not be a
> problem restarting these deamons as needed.  If the audio card leaves,
> there's no reason to have these processes hanging around.

This is broken then. Multiple PA processes can be run quite happily.
Each user has their own mechanism for communicating with the device via
a local unix socket file (so "networking" style APIs work but without
the actual networking part). This scheme is not overly original to PA,
lots of systems do it (e.g. X11, GPG Agent etc.), but PA's
implementation is fairly robust with protection from DoS attacks from
other users by not using a fixed location inside /tmp (using /home for
such special files can fail on NFS home directories as we need a local
disk for tmpfs for socket files).

Anyway, the whole fact that speech-dispatcher or speechd-up can only run
once is something that needs fixed IMO. The multi-seat example above is
one scenario where you'd want multiple versions running and the general
swap between idle and real user is another scenario where it could all
work nicely with multiple copies provided they played nice when the
system told them they no longer have "jurisdiction" over the machine/seat.

Col

-- 

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

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]