This is a description of a common problem encountered in a Linux computer running the accessibility
options of the
Orca GUI screen-reader and the
speakup console-mode screen-reader.
Description of the Problem
It is very common for a Linux distro which has the above mentioned accessibility tools installed and enabled to exhibit a very annoying problem.
- You have a desktop installed and when you start the computer you are given a graphical log-in prompt.
- Until you log-into the desktop, you can go to a virtual console (1 to 6), and the
- After you log-in to the
greeterand the desktop, the console falls silent.
What's going on?
There are a number of things happening here and the following components are involved:
espeakup, which is a program that connects
speech-dispatcher, which is a text-to-speech server program used by
pulseaudio, an audio library which is typically the default mechanism used by text-to-speech provided by
So Why Does it Work Until I Log-in to the Desktop?
Most Linux distros, in their default configuration, when access tech is enabled will do the following:
- Load the
speakupkernel modules necessary to run the console screen-reader.
- Start the
espeakupprogram that connects
- Start the greeter (the graphical log-in program).
These things might not happen exactly in this sequence but the end result is you will now be at the
graphical log-in, and (hopefully) you will have heard the immortal words screen-reader on, which
Orca saying hello.
Of course there is a whole lot more happening when Linux is starting up but these are the most relevant things to our subject.
Now we come to the crux of the issue...
In it's default configuration, the
espeak speech-synthesiser is compiled to use
pulseaudio if it
is running, and to use
ALSA if it is not.
That's a very important point to remember.
espeakup program which connects
espeak is run as a daemon by
the system. That is an important point, since it is not recommended, and in fact almost impossible,
pulseaudio as the
So, while we are sitting at a graphical log-in and have not actually logged in, this is the situation:
- An instance of
pulseaudiohas been started by the user under which the greeter is configured to run. So the greeter can use
- It is important to note that this instance of
pulseaudiois NOT running as your user.
- If you now go to a virtual-console by pressing the
ALTkey and any number from 1 to 6,
speakupwill speak and the console is accessible.
This is because currently
pulseaudio is not running for your user, so
espeak will use
If you now go back to the graphical console with
ALT+7, and log-in to the GUI desktop, the
pulseaudio run by the greeter will either die or at least stay in the background doing
nothing until you log-out back to the greeter, and another instance of
pulseaudio will be started
for your user. You will probably hear Welcome to Orca at this point as
Orca starts for you.
If you go back to the virtual-console where
speakup was working and making the console accessible
for you, it is now silent.
This is because
espeak now sees that
pulseaudio is running and tries to use it, but the
espeakup connector is running as
root so it will not work!
How to Fix it
For Debian, which is my distro of choice and a distro on which multiple others, including
Ubuntu are based, the easiest way is to switch
speech-dispatcher to use
ALSA instead of
Do the following:
- Either run
spd-confand set up a user
speech-dispatcherconfiguration and pick
ALSAwhen asked to choose an audio output method, or edit the
/etc/speech-dispatcher/speechd.conffile and change the
; autospawn = yesto
autospawn = no(uncomment by removing the semi-colon and change yes to no).
- Go to
/usr/share/alsaand delete anything with
pulsein the name, including anything in the
/usr/binunset the executable flag of
You may also have to add the greeter user to the
Now if you reboot you should again hear screen-reader on as the greeter loads and
but if you log-in to the graphical desktop, you should also have speech with
speakup if you drop
to a virtual-console.
ALSA can be a bit odd at times. I find you can sometimes get an effect, particularly when
scrolling rapidly down menus when the next highlighted option talks over the last one before that
finishes speaking, almost as if there are two speakers talking, but it works a whole lot better than
But if you run anything else that uses
pulseaudio as your user you will lose speech in the console
The only way to fix this is to recompile
espeak and change the
Makefile to stop
trying to use
pulseaudio if it is running.
If you do this you can then switch
speech-dispatcher back to
pulseaudio but I have never found
text-to-speech is as good with
pulseaudio as it is with