[pulseaudio-discuss] Accessing audio as root

[Bill Cox]

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?

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?  Probably because I've read some PA code,
and not CK, I'm thinking it would be easier and more robust.

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

Thanks,
Bill

On Sat, Jan 2, 2010 at 11:52 AM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> 'Twas brillig, and Bill Cox at 02/01/10 15:03 did gyre and gimble:
>> Hi, David.
>>
>> On Sat, Jan 2, 2010 at 1:08 AM, David Henningsson
>> <launchpad.web at epost.diwic.se> wrote:
>>> I was just thinking, and this idea is perhaps not 100% thought through,
>>> but it could be worth considering.
>>>
>>> We have this hand-over mechanism:
>>>
>>> http://git.0pointer.de/?p=reserve.git;a=blob_plain;f=reserve.txt
>>
>> You obviously know more about the plumbing than I do!  I don't know
>> anything about d-bus, so my opinion counts little, but it looks like a
>> good direction to me.  I would want to bury all the complexity of
>> dealing with d-bus under the pulse-simple API, so that only a one-line
>> change has to be made to clients like speakup/espeakup and
>> speakup/speechd-up.
>>
>> I'm not quite sure how this works.  When a speakup client wants access
>> to the sound card, it could request access at high priority, and then
>> plays it's sound.  How would it hand back the sound card to the other
>> user and uncork it?  If this were automatic once the queue was empty
>> for say one second, that would be great.  Is this the sort of thing we
>> can do with PA/CK?
>
> While this would theoretically work, I think it's probably not needed.
> The reservation system is really meant for interacting with jack and
> while it's not exclusive, I think it's not really an appropriate
> technique to solve this problem.
>
> I think the general concept of the speech dispatchers running as a
> system service is the bit that needs re-thought and that adding hooks to
> consolekit (if they don't exist) and the concept of an "idle user" are
> probably more practical long term solutions.
>
> Of course I could be wrong on that front :p
>
> 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/]
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>