Howdy,
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=fenrir
right
I know about users who run it on windows, BSD and MacOSX ;) so i assume it runs on Slint too.I'll let you know how that goes on Slint.
oh, i would be interested in why? Thats exact the kind of feedback i m looking for :). There are already a lot of fenrir only users out there :). but mostly on Arch based systems. so at least for them it seems to be able ;). let me know what you think or what is missing. code is nothing fixed or hammered in stone ;) .I don't think that can fully replace speakup though ;)
something off topic,i see in slint you ship KDE plasma. i want to give some attention here on our progress to make it accessible. you and maybe others here might be interested in.
see federiks (my mentor) blogpost: http://blogs.fsfe.org/gladhorn/2018/11/05/accessibility-update-kickoff-kicker-and-kwin-improvements/ or see some cherry picked status updates from mailing list: https://mail.kde.org/pipermail/kde-accessibility/2018-October/003245.html https://mail.kde.org/pipermail/kde-accessibility/2018-October/003251.html https://mail.kde.org/pipermail/kde-accessibility/2018-November/003259.htmlso the next version will have everything _basic_ on place to be able to initial work with KDE for blind people (First time in KDEs history!).
of course help is always welcome :).I have only good words to the KDE community. the guys there are very frindly and ready to help out where ever possible.
cheers chrys Zitat von Didier Spaier <didier@slint.fr>:
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, chrys@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 <didier@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, althoughespeakup be running.I am sorry, but I already spent too much time trying to understand how audioworks 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 andorca (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 audioworks 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=dsnoopSo using dmix is not the default in Debian?2) In /usr/share/alsa, remove the files pukse-alsa.conf andalsa.conf.d/alsa.conf, to avoid setting pulseaudio as the default plugin forapplications using Alsa when pulseaudio is running.I made these changes so that applications using pulseaudio and applicationsusing 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 couldcause 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 inthe thread "pulseaudio and espeakup" beginning with this message : https://lists.debian.org/debian-accessibility/2017/12/msg00089.htmlYes, 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 systemdidn't halt but was stuck with this message (from systemd, I assume): As stop job is running for Software speech output for SpeakupThis do not happens anymore after having replaced the espeakup binary by the oneshipped in Slint.That's an interesting point indeed, it really sounds like the daemon is getting stuck somehow. Samuel