[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Fwd: Re: loss of speech in speakup when switching between console and gui

-------- Forwarded Message --------
Subject: Re: loss of speech in speakup when switching between console and gui
Date: Tue, 6 Nov 2018 14:38:48 +0000
From: Keith Barrett <lists@barrettpianos.co.uk>
To: Didier Spaier <didier@slint.fr>

On 06/11/18 11:23, Didier Spaier wrote:

this is a follow-up, with bad news.

The tests I made that were successful were in console mode
(systemctl set-default multi-user.target)

However, they failed when in graphical mode:
(systemctl set-default graphical.target)

I go as far as re installing Debian Buster on bare metal (USB connected hard
disk), tried many things including all listed below to no avail: once Orca is
running in the Mate desktop if I type Ctrl+Alt+F2 I don't have sound, although
espeakup be running.

I am sorry, but I already spent too much time trying to understand how audio
works in Debian to investigate this issue, so I give up.
Hello Didier, please do not think that it is a waste of time, after your modification, speakup and orca work perfectly for me without pulseaudio installed which was not the case before.

I now have a perfectly useable system which I have not since May of this year, I cannot thank you enough for that usr/bin/espeakup replacement.

When lightdm is running but I didn't login yet, I can e.g. type Ctr+Alt+F2 and
login in this tty with speech, but as soon as I am logged in through lightdm and
orca (and pulse) is started for a regular user I have no more sound.

I tried with and without autospawn of pulse, same bad result.

I am sorry, but I already spent too much time trying to understand how audio
works in Debian to investigate this issue, so I give up.

I will just answer questions from Debian folks, if any.

Meanwhile, my advice to blind Linux users is to use Slint
Or to remove the dreaded pulseaudio and use your modification. Do you intend to keep the file available for download, I am sure it will be appreciated as it makes debian useable once more as long as pulseaudio is purged from the system.


Best regards,


On 02/11/2018 01:42, Samuel Thibault wrote:

(I reordered things a bit to make the story clearer for pulseaudio
maintainers in Cc)

Didier Spaier, le ven. 02 nov. 2018 01:13:09 +0100, a ecrit:
This message is an answer to the thread started by:

@Keith: If you don't use pulseaudio, the issue could be an unexpected
consequence of applying since Thu, 03 May 2018 the patch audio-pause:
"Pause espeak when the console is switched to a graphical VT"

Well, I believe that report is just another case of the well-known issue
that once pulseaudio is started in X (e.g. for orca), it holds the ALSA
card completely and espeakup can't take it again.  The pause patch makes
espeakup release the ALSA card so that pulseaudio triggered by Orca can
take it. This is considered a better behavior than not getting any audio
inside X just because espeakup holds the ALSA card.

I then made these changes:
1) Edit /etc/pulse/default.pa to append these lines:
load-module module-alsa-sink device=dmix
load-module module-alsa-source device=dsnoop

So using dmix is not the default in Debian?

2) In /usr/share/alsa, remove the files pukse-alsa.conf and
alsa.conf.d/alsa.conf, to avoid setting pulseaudio as the default plugin for
applications using Alsa when pulseaudio is running.

I made these changes so that applications using pulseaudio and applications
using alsa directly can nicely coexist, not stepping on each others toes.

I don't know if the modifications I made are acceptable by the Debian
authorities though ;)

There is no such thing like "Debian authorities".
There are the maintainers of the pulseaudio stack, which define a
default configuration which aims at the most common case.  I don't know
why dmix is not part of it, that's with them to be discussed, e.g. in a
bug report. Making pulseaudio share the device with alsa thanks to dmix
seems like an option indeed, that you could document on
I don't know what counterparts there might be to it, again pulseaudio
maintainers will know better.

I also disabled autostarting of pulseaudio at the user level, appending:
"Hidden=true" to the file /etc/xdg/autostart/pukseaudio.desktop but maybe that
doesn't matter. Anyway pulseaudio is spawned by the applications that need it.

And notably here by Orca, so I don't think that is involved here.

But these changes were not sufficient to solve the issue so I had a look at the
speakup Debian package. Seeing the aforementioned patch I thought that it could
cause the issue. To check I just replaced /usr/bin/espeakup by the binary
shipped in Slint and it worked.

Ok, so somehow espeakup doesn't manage to take the ALSA card again once
pulseaudio is started in X?  It'd be interesting to check with the patch
(i.e. the Debian binary)

- whether starting espeakup only after running pulseaudio in X works (in
   which case it's the espeakup resume which fails).

- a backtrace of espeakup when it failed to resume, i.e. attach a gdb to
   it and run thread apply all bt full. One such kind of trace was posted
   on http://linux-speakup.org/pipermail/speakup/2018-October/061491.html
   I haven't found the time to really look at it yet, various things have
   kept popping up.

I understand that you won't be interested by my settings of alsa and pulseaudio
as you don't use pulseaudio, but this could also solve the issue mentioned in
the thread "pulseaudio and espeakup" beginning with this message :

Yes, thus documenting on the wiki, so people can configure it even if
pulseaudio maintainers prefer not to set it by default.

Oh, and I almost forgot: with the patch when rebooting from Mate the system
didn't halt but was stuck with this message (from systemd, I assume):
As stop job is running for Software speech output for Speakup
This do not happens anymore after having replaced the espeakup binary by the one
shipped in Slint.

That's an interesting point indeed, it really sounds like the daemon is
getting stuck somehow.


Reply to: