[pulseaudio-discuss] Accessing audio as root

[Bill Cox]

Hi, Colin.  I disagree that speech-dispatcher and speechd-up are
broken and need to be fixed.  speechd-up is a root daemon attached to
the /dev/softsynth device.  I see no utility in having multiple copies
of it.  Speech-dispatcher opens an IP port to act as a speech server
over the network.  It's kind of a silly feature, but why should I
second-guess the speech-dispatchers developers and break it?

IMO, what's broken is PA.  I can't in Ubuntu get two copies running on
the same machine without borking the sound system.  If PA can't even
do it, why should I mangle all the accessibility apps out there by
making them try to follow PA's overly complex model?  This has to be a
screaming violation of the KISS rule.  The sound system is a bit
complex.  Fine.  To use it, you need to make all your apps complex?
Really?

The complexity has to be contained.  It can't keep leaking out of PA
into the rest of the system, making it more and more unstable as it
goes.

Bill

On Sun, Jan 3, 2010 at 5:43 AM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> '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/]
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>