[pulseaudio-discuss] Using pulseaudio with speakup

[Bill Cox]

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.

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

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

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

Bill

On Sat, Jan 2, 2010 at 10:01 AM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> 'Twas brillig, and Bill Cox at 02/01/10 14:20 d isid gyre and gimble:
>> Hi, Colin.  Here's what I'm thinking of doing.  I think PulseAudio
>> should support the concept of a "global" sound source attached to a
>> card, and whichever pulseaudio system has rights to use the card
>> should be responsPible for processing the global source.  Any
>> pulseaudio client could declare themsevles a "global" source, but to
>> be considered authorised, they must be of a special global source
>> group, or perhaps run as a special global source user.
>
> This is quite easy to say but certainly very difficult to actually
> "write". Even if there are 5 users logged in and running 5 separate PA
> instances, each users' PA clients will be talking to totally separate PA
> daemons and each will be essentially ignorant of the others existence
> (as they should be).
>
> There is something that can be done however....
>
>> It is clear to me, and I hope becoming clear to you, that there are a
>> few special cases where a process needs continuous access to the sound
>> card, and needs to share it with the user.  Speakup is one.  But even
>> looking at this, it's actually multiple cases.  Speakup just creates
>> the /dev/speakup_soft device, which speakup clients read to produce
>> speach.  Two popular drivers exist, both with PA backends:
>> speechd-up/speech-dispatcher, and espeakup.  I'm sure there are more
>> reasons for other sound drivers to be considered "global".
>
> With this module, is there any reason to not write a PA module that
> processes this /dev/speakup_soft node and does the necessary? e.g. the
> speechd-up or espeakup code basically ported to a PA module?
>
> It doesn't really solve the overall problem of when to start it tho', so
> not sure it's really worth it. PA will be started at X11 login or when
> it is "needed" (e.g. something tries to output sound and PA is not yet
> running) via it's autospawning system.
>
> Having "module-speakup" will not cause autospawning, so it would rely on
> PA being started for it to work, which is the same situation as currently.
>
> I sent a (rather long) reply earlier today that talks about making
> console-kit aware of "idle" state and having various hooks for it. I
> think (at the moment) that this is probably the right direction for
> accessibilty apps. i.e. PA just works as normal (and is launched when
> needed) but console-kit itself is the thing that can be used to hook
> into for an accessible system.
>
> I'm happy to accept counter arguments tho'!!
>
>> Would this scheme be in keeping with PA security?  It seems to me that
>> it would be pretty secure: it's only a sound source, and there's no
>> possibility of accessing the mic, for example, and only special
>> processes can use it.
>
> I think it would be fine, but again the problem is more related to
> starting PA in the first place not so much it dealing with a "global
> source" per se.
>
> I hope the longer reply from earlier today is understandable and I'm not
> smoking too much crack :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
>