I have in my TODO list to try fenrir, so thanks for the reminder Chrys. I guess that the PKGBUILD is here: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=fenrir I'll let you know how that goes on Slint.
I don't think that can fully replace speakup though ;) Anyway the issue of switching between console and graphical modes in Debian remains. Best regards, Didier On 06/11/2018 13:44, ch...@linux-a11y.org wrote: > Howdy, > > i dont want to ditch speakup, but you also may want to try out fenrir :). i > got a lot of positive feedback from archLinux users where i can provide an > PKGBUILD for. in fact F123 is basing its images for low budget computers on > that screenreader. so its very fast too, witout need of digging around in > kernel. I m not blind, but i mostly created it based on information and > wishes i got from blind users (you may know i.e. storm_dragon, Kyle or deedra > from orca list). you can make it go away for GUI or controll it via the > remote manager to make it fill the needs at runntime. for pulseaudio i > provide some simple setup scripts. > I would be happy to see some testers on other distros then archlinux too :). > what makes me able fix up issues for other distos like debian too. > > it can also just run in an GUI terminal without need an 3rd party software > like an patched version of screen or tmux. > > cheers chrys > Zitat von Didier Spaier <did...@slint.fr>: > >> 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
