[pulseaudio-discuss] Using pulseaudio with speakup

[Colin Guthrie]

'Twas brillig, and Bill Cox at 02/01/10 14:20 did 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/]