Skip to main content

The speakup/espeakup/pulseaudio Problem

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.

  1. You have a desktop installed and when you start the computer you are given a graphical log-in prompt.
  2. Until you log-into the desktop, you can go to a virtual console (1 to 6), and the speakup screen-reader works.
  3. After you log-in to the greeter and the desktop, the console falls silent.

What's going on?

There are a number of things happening here and the following components are involved:

  • eSpeak software speech-synthesiser.
  • The speakup console screen-reader.
  • espeakup, which is a program that connects speakup to espeak.
  • speech-dispatcher, which is a text-to-speech server program used by Orca.
  • pulseaudio, an audio library which is typically the default mechanism used by text-to-speech provided by speech-dispatcher and hence Orca.

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:

  1. Load the speakup kernel modules necessary to run the console screen-reader.
  2. Start the espeakup program that connects speakup to espeak.
  3. 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 is 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.

And the espeakup program which connects speakup to espeak is run as a daemon by the system. That is an important point, since it is not recommended, and in fact almost impossible, to run pulseaudio as the root or system user.

So, while we are sitting at a graphical log-in and have not actually logged in, this is the situation:

  • An instance of pulseaudio has been started by the user under which the greeter is configured to run. So the greeter can use pulseaudio to make Orca speak.
  • It is important to note that this instance of pulseaudio is NOT running as your user.
  • If you now go to a virtual-console by pressing the ALT key and any number from 1 to 6, speakup will speak and the console is accessible.

This is because currently pulseaudio is not running for your user, so espeak will use ALSA.

If you now go back to the graphical console with ALT+7, and log-in to the GUI desktop, the instance of 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.

Conclusion

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

Do the following:

  1. Either run spd-conf and set up a user speech-dispatcher configuration and pick ALSA when asked to choose an audio output method, or edit the /etc/speech-dispatcher/speechd.conf file and change the AudioOutputMethod to ALSA.
  2. In /etc/pulse edit client.conf and change ; autospawn = yes to autospawn = no (uncomment by removing the semi-colon and change yes to no).
  3. Go to /usr/share/alsa and delete anything with pulse in the name, including anything in the alsa.conf.d sub-directory.
  4. In /usr/bin unset the executable flag of start-pulseaudio-kde and start-pulseaudio-x11.

You may also have to add the greeter user to the audio group.

Now if you reboot you should again hear screen-reader on as the greeter loads and Orca starts, but if you log-in to the graphical desktop, you should also have speech with speakup if you drop to a virtual-console.

Final Notes

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

But if you run anything else that uses pulseaudio as your user you will lose speech in the console again.

The only way to fix this is to recompile espeak and change the Makefile to stop espeak ever 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 ALSA.