Hello, On 02/11/2018 01:42, Samuel Thibault wrote: >> 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. To check, I applied the Debian patch audio-pause against espeakup-0.80 in Slint, rebuilt and installed a package repkacing the previously installed one. I observed in Slint the same behavior as in Debian: no speech from espeak when going back to console mode from graphical mode. All was correct again installing back the previous package, without the patch. Looks like a confirmation, I think. >> 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. I couldn't check that in Slint because we don't use systemd. Didier
Attachment:
0xD50202EF60C03EEA.asc
Description: application/pgp-keys