loss of speech in speakup when switching between console and gui

Tue Nov 6 11:23:03 GMT 2018

Hello,

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.

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 ;)

Best regards,

Didier

On 02/11/2018 01:42, Samuel Thibault wrote:
> Hello,
> 
> (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:
>> https://lists.debian.org/debian-accessibility/2018/10/msg00000.html
>>
>> @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
> http://wiki.debian.org/accessibility
> 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 :
>> https://lists.debian.org/debian-accessibility/2017/12/msg00089.html
> 
> 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.
> 
> Samuel
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xD50202EF60C03EEA.asc
Type: application/pgp-keys
Size: 2153 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-pulseaudio-devel/attachments/20181106/8c02b8c8/attachment.key>