[pulseaudio-discuss] Accessing audio as root

[Colin Guthrie]

'Twas brillig, and Bill Cox at 02/01/10 21:03 did gyre and gimble:
> Hi, Col.  I'm willing to try the aproach you suggest, but I'd like to
> debate the implementation some more.  If I understand correctly, I can
> use CK to determine whenever the sound card permissions are moved to a
> new user (which is basically whenever a user takes over the "seat",
> except as root), and can then launch the various accessibility apps
> the user needs as that user.  Is this basically correct?  Since there
> are several apps that are candidates, I'm tempted to allow them to be
> listed in some /etc config file, rather than duplicating the code for
> each.  That would provide users a mechanism for having apps follow the
> sound card.  Should I make this a PA capability with a PA module?

Right in principle but not quite what I was suggesting in practice.

Essentially I am suggesting that console kit is altered to have a set of
hooks that it itself runs.

Your system will be running the console-kit-daemon and it already has
folders like:

/usr/lib/ConsoleKit/run-session.d

Which is run when a new user logs in.

What I am suggesting is to add the concept of the "idle" session and a
system "idle" user.


> If I made this a PA module, and if I'm basically trying to kill client
> apps when PA loses a sound card, and launch client apps when it gains
> a sound card, then might it make sense to add a hook within PA to do
> this, and not deal with CK?

No, this is totally impossible - remember that there are multiple PA
processes, one for each user. The above suggestion would only work if
there was a single PA daemon for all users. This is why I think
console-kit is the correct place to do this - there is a single
system-wide daemon running here and it already has a hooks system.

PA clients should never be killed - they will just be corked if the user
becomes inactive and uncorked when they become active again.


>  Probably because I've read some PA code,
> and not CK, I'm thinking it would be easier and more robust.

Sadly this is the wrong concept and not what I've actually been
suggesting. I'd recommend you read up on console-kit a bit and perhaps
speak to some of their devs about it and see whether what I'm suggesting
is sensible or not.

> Why do I need to have an idle hook?  It sounded good when I read it
> the first time, but now I'm confused.

This is the key thing about what I'm suggesting. When you switch to the
login prompt on tty1, there is no active user but yet you still want the
prompt to be read out and have sound. For this I suggest adding the
concept of an idle system. This should be the same as the gdm login
screen really but it runs a real (albeit psuedo) session under the gdm
user. The same is not true for tty logins which is why I think an idle
user should take this job. It may or may not make sense for gdm to be
run as the idle user too rather than it's own dedicated user.

Anyway when the system becomes idle (e.g. tty1 prompt) this basically
means no user is active and implies either a status screen or a login
prompt. When the user becomes idle the hooks installed to consolekit by
the speechd-up package will cause the speechd-up daemon to be run. This
daemon will then be able to speak the login prompt. When the user logs
in, console-kit will be informed about this and the idle session will be
killed (or suspended) and then the user's own session will be start. The
hooks for "user logs in" in consolekit can then start a speechd-up
process for that user if it's not already running (if it's running
already from a graphical session and the user switches to tty1 and logs
in the speechd-up already running from the graphicial login will just be
reused).

This is very much the same principle as pulseaudio itself (e.g. one PA
process runs for a given user even if they are logged in mulitple
times). The difference from PA is that speechd-up cannot use
autospawning to launch, which is why I'm suggesting leveraging
console-kit to actually *start* the speechd-up process.

I'm probably not explaining it very well so I'll try and reiterate when
I'm not quite as tired with a few examples.

Col

(Of course all my suggestions today could be way off base so it would be
much better if someone more familiar in the inner workings could
validate (or invalidate!) what I've said before you go off and do
anything implementation wise!)


-- 

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/]