[pulseaudio-discuss] Accessing audio as root

[Colin Guthrie]

'Twas brillig, and Bill Cox at 03/01/10 12:41 did gyre and gimble:
> 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?

I think a system service that can convert plain text to speech PCM is a
fair enough call, but the bit that actually outputs the sound should
very much be a per-user thing. It's a per-user choice whether or not to
output this (with a system-wide setting for when the system is idle - on
a shared system for both blind and sighted users I'm sure the sighted
users accept the need for the speech synthesis at the login stages). If
this is a system wide "outputer" then it needs to have it's own
preferences system built in to determin whether or not a given user
wants to have the speech enabled or not. I don't think it's right that
such apps have to recreate a user preferences system internally or read
files in users home directories for preferences (e.g. if a user has an
encrypted home dir this could cause some complications). It makes much
more sense to run this bit as the user that is running the system. This
is a pretty accepted approach I believe.

> 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? 

I think this is a problem on your setup and I've seen no evidence yet
that it is PA that is at fault here (not ruling it out). I also do not
think this model is overly complex. Daniel (the Ubuntu PA guy) has
already said that he cannot reproduce this problem and he said he'd like
to help you get it working, so I think you should accept his offer and
try and work out where the problem is.


> 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?

No. 99.9% of apps run as the user and no additional complexity is
needed. This accessibility system is an exception to that rule and as a
result does need to be designed properly to fit in with a modern system.
The actual approach I've described is actually totally generic and
pretty simple when it's boiled down. I've maybe not explained it too well.

> 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.

To be honest I think this is an overreaction due to you being very
involved in this specific use case. I agree is different to what is
happening now but even with the current approach there are numerous
problems:
 1. Different users on the system need their preferences managed by the
central app, not via a simple per-user preference scheme common to
99.99% of apps.
 2. Encrypted home directories could cause problems.
 3. Multi-seat systems could cause problems.
 4. Permissions are sub-optimally secure to allow this to work.

All in all the approach I describe is much more modern and forward
thinking IMO. Yes it needs apps to be updated, but then there are not
many apps that are still in use today that are identical to how they
were initially written 20 years ago! Everyone has got to move with the
times and paradigms.

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