[pulseaudio-discuss] Using pulseaudio with speakup

[Colin Guthrie]

'Twas brillig, and Bill Cox at 02/01/10 16:04 did gyre and gimble:
> Hi, Colin.  Sorry about always replying at the top.  This is the usual
> custom for the blind, as they can't easily skip down to the new stuff.

No problem, exception to bottom posting duely noted :)

> I'd prefer not to write new PA modules for each accessibility driver.
> I think it's very important to make it as easy as possible for
> existing accessibility drivers to work seamlessly with PA, and we
> don't want to polute the PA module space with a dozen accessibility
> modules (there are actually quite a lot of programs that talk - I've
> just mentioned the most important).

Yeah, that makes sense and like I said even writing a module doesn't
actually solve the problem anyway, so probably best to ignore this.

> I like your suggestion of CK understanding an idle state.  Does it
> already have hooks for when applications pause their audio?  How about
> if they disable the mic?  

No, console-kit isn't aware of audio per-se. It's just a generic part of
the core infrastructure tracking user logins, active sessions etc.

> Another important accessibility feature is
> speech-recognition.  You aren't hearing from a bunch of mad users who
> can't type simply because Linux speech recognition basically sucks
> right now.  When that changes, we're going to need the speech
> regcognition engine to play nicely just like speakup.  Users will need
> to speak their login and password, and they'll need it when they su to
> root.  

That may be a larger problem due to user permissions etc. (e.g. why
should the idle user be allowed to send keys to mingetty etc.) but I'm
sure there will be a way to solve this (some sort of setuid app to send
the keys or similar).


> Does CK have a way to tell Skype running as "bill" that the
> speech-recognition engine running as "dragon-dictate" has corked it's
> use of the mic?

No, this is not what CK is all about.

Also remember that the ultimate goal is to always run apps as the user
that is currently active: e.g. dragon-dictate (the application) would
run as bill (the user) or as the idle user in the case of a login prompt.

> Adding such hooks, or using existing ones sounds very promising to me,
> though I'm nearly 100% ignorant currently of CK.

Well we're all ignorant of something until we look into it :)

As I said above, all ck does is track which users are logged in (e.g. on
tty consoles, on X11 sessions, via SSH etc). It will generally only
designate one user as active per seat (most machines only have one seat,
but you can run a multiseat setup with relative ease). This information
is used to let the "active" user get direct access to the machines
resources - e.g. the sound hardware, the video hardware etc. All
pulseaudio really does is listen to console-kit and honour what it says
is the case - only allowing the currently active user access, but still
providing a structure and framework for apps so that they don't just
crash or behave badly when they suddenly have their audio rights yanked
away from them.

We can just use the information exposed from CK to know when we are or
are not "active". The ultimate goal is to run as many apps as possible
under the user account of the person using them. Every other system user
that allows regular users to communicate with them is a potential
privilege escalation hole.

So the suggestions I've made are basically to run the apps at the
appropriate times as the appropriate user using console-kit as the
central information source as to what the active user actually is.

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