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 >
