[pulseaudio-discuss] Accessing audio as root
waywardgeek at gmail.com
Mon Jan 4 11:59:10 PST 2010
Hi, Lennart. I beg you to not work towards eliminating the consoles.
Speakup is not only popular, but easily installed as a module in
Ubuntu, with 'm-a a-i speakup-souce'. Even sighted users prefer to
have those consoles available when X goes nuts, and for the blind,
they need it whenever speech stops, which happens whenever X11,
Compiz/Metacity, Orca, speech-dispatcher, or PA stops working. It's
the nature of open source software that users break it often, and they
need the consoles to get back on track. Many blind users use the
consoles mainly, and only switch to Gnome to access web sites that
can't be handled by text-based browsers like elinks.
Users need the consoles, and thus speakup, after logging in through
gdm for several reasons. Most blind users feel speakup is a better
console driver than Orca driving gnome-terminal, and they spend as
little time in Gnome as possible. I hear it integrates well with
To put it simply, I cannot even imagine creating a Vinux distro (linux
for the blind) without speakup and consoles!
On Mon, Jan 4, 2010 at 1:58 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Fri, 01.01.10 23:50, Bill Cox (waywardgeek at gmail.com) wrote:
>> > On Fedora at least the screenreader runs as normal process in the gdm
>> > pseudo-session which also happens to run a PA instance. So everything
>> > should be fine here, and I am quite sure this is not only done on
>> > Fedora this way but all other distributions that use a current version
>> > of gdm.
>> Lennart, let me explain how blind people use Linux. There are TWO
>> applications in common use - Orca and Speakup. Actually, there's a
>> third - emacspeak, but let's not go there, yet. Orca is the screen
>> reader that you are talking about. It runs as user, and can be made
>> to work well with PulseAudio. I've personally helped in that effort
>> (I wrote a new pulseaudio driver for it). The other critical
>> application is Speakup. It runs as a kernel module and speaks every
>> bit of console output during the boot process. Many blind people rely
>> heavily on Speakup, and only use Orca for websites that require
>> Firefox to read.
> Hmmm, speakup is not supported in fedora anymore, afaik. The kernel
> patch never got merged upstream, did it? And there are no plans for
> that either, are there? It doesn't really particularly increase my
> interest in supporting something like this if there is no push to get
> this merged upstream into kernels and the major distributions.
> In Fedora our plans are mostly to get rid of the console entirely in
> the long run anyway, its not shown anymore by default already.
> But anyway, if we want to support this, how was the traditional
> handing over of the audio device done between speakup and the orca tts
> stuff done? Why isnt the speakup tts daemon run inside a
> pseudo-session similar to how gdm handles this when running orca
> inside of a pseudo-session? To me it sounds that if we want to do the
> handover properly anyway the cleanest way would be for speakup to
> simply call into ckit to register a pseudo-session. Then during bootup
> we would first run that speakup tts daemon in a speakup ck
> session. Then, when gdm starts up we'd run orca in the gdm session,
> and finally run orca in the user sessio, and hence have two handovers
> in the whole process: from speakup to gdm and from gdm to proper
>> speaking all console output to the user. The blind don't give a hoot
>> how we get speach from /dev/speakup_soft to the sound card. It just
>> has to happen. Today, on every pulseaudio enabled system I know of,
>> this does not work properly. I tried setting speakup to use alsa, and
>> it works, right up until pulseaudio for gdm starts. After that,
>> speakup is mute. Is there any way for pulseaudio to share the sound
>> card with speakup/alsa?
> Why do you need speakup anymore after gdm is started up?
> Lennart Poettering Red Hat, Inc.
> lennart [at] poettering [dot] net
> http://0pointer.net/lennart/ GnuPG 0x1A015CC4
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
More information about the pulseaudio-discuss