When I start running espeakup then run emacspeak or speechd-el and then
return to espeakup the espeakup speech is trashed and barely
understandable. This all can happen on the text console with no need
whatever to touch graphics interface. Neither running any of the
alternative screen readers like flite or festival helps this situation
either. For those with usb or serial or parallel speech synthesizers
perhaps outsourcing some of this work to those synthesizers might help a
little but that does nothing for those who only have a sound card.
On Sat, 30 Dec 2017, Samuel Thibault wrote:
Date: Fri, 29 Dec 2017 19:11:51
From: Samuel Thibault <sthiba...@debian.org>
To: pkg-pulseaudio-de...@lists.alioth.debian.org
Cc: debian-accessibility@lists.debian.org
Subject: pulseaudio and espeakup
Resent-Date: Sat, 30 Dec 2017 00:12:25 +0000 (UTC)
Resent-From: debian-accessibility@lists.debian.org
Hello,
Incompatibility between espeakup and pulseaudio is a recurring issue
which AIUI has never actually been settled (or nobody took the time to
implement a solution in Debian).
This is a real pain for blind users, there are loads of reports that
Debian/Ubuntu systems are not accessible, or accessible only in text
mode, or accessible only in graphical mode, none of which is an
acceptable situation.
In summary:
- espeakup is a speech synthesis for the in-kernel speakup screen
reader.
- espeakup runs as a background daemon which essentially reads
/dev/softsynth and uses libespeak-ng to emit speech.
- It can be made to run as non-root user by adding udev rules for
/dev/softsynth to be accessible for it.
- libespeak-ng is able to use pulseaudio
BUT
- currently espeakup runs as root, and then takes over the ALSA device.
orca inside lightdm or gdm then can't emit its output (unless by luck
espeakup didn't say anything at boot, and then pulseaudio inside the
lightdm/gdm session manages to get the device, but then it's espeakup
which can't get the device).
- espeakup could be made to run as normal user, but then it seems its
pulseaudio server can't access audio, I guess that's because consolekit
doesn't consider it to be running "on the console"?
- espeakup and lightdm/gdm could be given audio group access, but then
there are two competing pulseaudio servers, and only the first one seems
to actually manage to emit sound.
In the end, I have no idea how this situation is supposed to work, and
for now I have just made the espeakup d-i script *purge* pulseaudio,
to get things working. Of course I can see various documentations
saying one could use a system-mode daemon, but upstream doesn't want
that. Normally, espeakup could have its own pulseaudio server, playing
well along pulseaudio servers of other users, but I failed to get
something working.
Any thoughts?
We really need to fix this (and I'm really depressed that it seems
nobody took the time to manage to work out a solution).
Samuel
--
