[pulseaudio-discuss] Accessing audio as root

[Bill Cox]

This scheme sounds reasonable, though whenever someone says
"impossible", I'm naturally inclined to give it a solid try.  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.  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.

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.  There can
only be one speechd-up and one speech-dispatcher process at a time.
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.

Bill

On Sat, Jan 2, 2010 at 4:47 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> '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/]
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>