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 >
0xD50202EF60C03EEA.asc
Description: application/pgp-keys
