Re: loss of speech in speakup when switching between console and gui
On 13/11/2018 00:42, Samuel Thibault wrote: Hello, Keith Barrett, le mar. 02 oct. 2018 17:04:37 +0100, a ecrit: I am loosing speech in the console using speakup after switching back from the desktop. To reproduce, log in to the desktop and make sure orca is working. Then switch to one of the text consoles with control alt f4. Result for me is that speakup is no longer working. This happens more the 50 percent of the time. I have found an issue in libespeak-ng which makes it hang on getting put on pause. Could you try the packages on https://people.debian.org/~sthibault/tmp/sid-tmp/libespeak-ng1_1.49.2+dfsg-7~0_amd64.deb https://people.debian.org/~sthibault/tmp/sid-tmp/espeak-ng-data_1.49.2+dfsg-7~0_amd64.deb which seem to be fixing the issue in my tests. Yes, it is working here as well. Thanks for the fix! Samuel
Re: loss of speech in speakup when switching between console and gui
On Tue, 13 Nov 2018, Samuel Thibault wrote: Hello, Keith Barrett, le mar. 02 oct. 2018 17:04:37 +0100, a ecrit: I am loosing speech in the console using speakup after switching back from the desktop. To reproduce, log in to the desktop and make sure orca is working. Then switch to one of the text consoles with control alt f4. Result for me is that speakup is no longer working. This happens more the 50 percent of the time. I have found an issue in libespeak-ng which makes it hang on getting put on pause. Could you try the packages on Hi Samuel, Yes, it works. Thaks for your pretty work.> https://people.debian.org/~sthibault/tmp/sid-tmp/libespeak-ng1_1.49.2+dfsg-7~0_amd64.deb https://people.debian.org/~sthibault/tmp/sid-tmp/espeak-ng-data_1.49.2+dfsg-7~0_amd64.deb which seem to be fixing the issue in my tests. Samuel
Re: loss of speech in speakup when switching between console and gui
Hello, Keith Barrett, le mar. 02 oct. 2018 17:04:37 +0100, a ecrit: > I am loosing speech in the console using speakup after switching back from > the desktop. > To reproduce, log in to the desktop and make sure orca is working. > Then switch to one of the text consoles with control alt f4. > Result for me is that speakup is no longer working. > This happens more the 50 percent of the time. I have found an issue in libespeak-ng which makes it hang on getting put on pause. Could you try the packages on https://people.debian.org/~sthibault/tmp/sid-tmp/libespeak-ng1_1.49.2+dfsg-7~0_amd64.deb https://people.debian.org/~sthibault/tmp/sid-tmp/espeak-ng-data_1.49.2+dfsg-7~0_amd64.deb which seem to be fixing the issue in my tests. Samuel
Re: loss of speech in speakup when switching between console and gui
On Thu, Nov 1, 2018 at 9:42 PM 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/msg0.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? > No. Pulseaudio by default does not use dmix, and talks only to "real" hardware. I'm not sure how dmix works, but I don't think that you can use multiple devices (ie, hdmi vs speakers) if you are only interacting with the virtual dmix device. > > > 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. > As mentioned above, pulseaudio allows outputting to multiple devices at the same time. > > > 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. > There are two possible mechanisms for autostarting: 1. systemd --user (the default on linux). You can use `systemctl --user mask pulseaudio.socket pulseaudio.service` to disable pulseaudio. 2. Autospawn (default on non-linux). You can disable it by editing ~/.config/pulse/client.conf (or /etc/pulse/client.conf) and setting autospawn to false. > > > 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). > Pulseaudio should release the soundcard once you leave your X-session... unless you are already logged in in the target tty. The way this works is that systemd-logind detects which user is "in front of the screen", and grants access to /dev/snd/foo to that user. If you are not logged in the console, then systemd-logind should take away the permissions, and pulseaudio would react accordingly by releasing the device. If you are already logged in in the target console, then systemd-logind will not take away the permissions, so pulseaudio would still keep the device open. > > - 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 : > >
Re: loss of speech in speakup when switching between console and gui
On 06/11/2018 20:04, Didier Spaier wrote: > Well we still ship KDE4 for now, so that'd be after the release of Slackware > 15, maybe mid-2015, if it ships plasma 5. Please read mid-2019, and that's just an uninformed forecast. 0xD50202EF60C03EEA.asc Description: application/pgp-keys
Re: loss of speech in speakup when switching between console and gui
Hello, On 06/11/2018 14:52, ch...@linux-a11y.org wrote: >> I'll let you know how that goes on Slint. > I know about users who run it on windows, BSD and MacOSX ;) so i assume it > runs on Slint too. It does, I hear a sound when it starts and: didier[~]$ ps -ef|grep fenrir didier2810 2796 1 19:49 pts/000:00:00 fenrir didier2811 2810 0 19:49 pts/000:00:00 /usr/bin/python3 /usr/bin/fenrir didier2813 2810 0 19:49 pts/000:00:00 /usr/bin/python3 /usr/bin/fenrir didier2818 2810 0 19:49 pts/000:00:00 /usr/bin/python3 /usr/bin/fenrir didier2822 2810 0 19:49 pts/000:00:00 /usr/bin/python3 /usr/bin/fenrir didier2833 2796 0 19:50 pts/000:00:00 grep fenrir didier[~] However I don't know how to make it read anything and the keyboard commands don't work although i have installed these deps: python-evdev-1.0.0 pyudev-0.21.0 dbus-python3 >> I don't think that can fully replace speakup though ;) > 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 ;) . Fenrir is mutually exclusive of speakup on the console and orca in graphical mode, which both work well enough. I'd need to know what benefit could bring to Slint users using fenrir instead before investing more time testing it. > 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. Well we still ship KDE4 for now, so that'd be after the release of Slackware 15, maybe mid-2015, if it ships plasma 5. Thanks for your effort anyway If you want to further discuss fenrir or Slint I suggest that we do that elsewhere not to spam this list. Best regards, Didier 0xD50202EF60C03EEA.asc Description: application/pgp-keys
Re: Fwd: Re: loss of speech in speakup when switching between console and gui
Hello, On 06/11/2018 15:56, Keith Barrett wrote: > Do you intend to keep the file available for download, I am sure it will be > appreciated as it makes debian usable once more as long as pulseaudio is > purged from the system. Well, I am not comfortable storing permanently binary files without context and associated source files, even in a testing repository. But the source files are here: http://slackware.uk/slint/x86_64/slint-14.2.1/source/espeakup/ The build script is: http://slackware.uk/slint/x86_64/slint-14.2.1/source/espeakup/espeakup.SlackBuild The Slint package is there: http://slackware.uk/slint/x86_64/slint-14.2.1/slint/espeakup-0.80-x86_64-7slint.txz Basically, you can just download it, untar it (it's just a compressed archive) then reuse usr/bin/espeakup that you'll find in the tree. But it'd be better to rebuild that locally to avoid dependencies issues, that's basically just a matter of make & make install, nothing fancy. Just make sure you have espeak-ng installed. Didier 0xD50202EF60C03EEA.asc Description: application/pgp-keys
Re: loss of speech in speakup when switching between console and gui
Howdy, https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=fenrir right I'll let you know how that goes on Slint. I know about users who run it on windows, BSD and MacOSX ;) so i assume it runs on Slint too. I don't think that can fully replace speakup though ;) 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 ;) . 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.html so 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 : 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 : 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/msg0.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.
Fwd: Re: loss of speech in speakup when switching between console and gui
Forwarded Message Subject: Re: loss of speech in speakup when switching between console and gui Date: Tue, 6 Nov 2018 14:38:48 + From: Keith Barrett To: Didier Spaier On 06/11/18 11:23, Didier Spaier wrote: 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. Hello Didier, please do not think that it is a waste of time, after your modification, speakup and orca work perfectly for me without pulseaudio installed which was not the case before. I now have a perfectly useable system which I have not since May of this year, I cannot thank you enough for that usr/bin/espeakup replacement. 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 Or to remove the dreaded pulseaudio and use your modification. Do you intend to keep the file available for download, I am sure it will be appreciated as it makes debian useable once more as long as pulseaudio is purged from the system. ;) 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/msg0.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
Re: loss of speech in speakup when switching between console and gui
On 04/11/18 18:36, Samuel Thibault wrote: Keith Barrett, le dim. 04 nov. 2018 18:32:41 +, a ecrit: On 04/11/18 13:48, Didier Spaier wrote: On 04/11/2018 14:37, Keith Barrett wrote: On 03/11/18 19:54, Didier Spaier wrote: Hello, I should have stated that this binary is a 64-bit one. Maybe you have a 32-bit system? No, I have a 64-bit system. Just thinking about it later, could it be a permissions/ownership issue? i Just in case, try again, this time typing as root after having copied the file: chown root:root /usr/bin/espeakup chmod 755 /usr/bin/espeakup. Success, it must have been permissions. I have been switching between X and the console and so far, after a few hours, no crashes at all. Thank you Didier for your efforts, a long standing issue solved for me, can we get the change included in debian? Not that simply since as I mentioned the setup that Didier uses is not the default setup configured by the pulseaudio package. That needs to be discussed with pulseaudio maintainers. Samuel Hello Samuel, Until the issues can be resolved, is it possible then when installing using speech to not have the install install pulseaudio and to add Didier's modification? To recap, this means that switching between the console and graphical interface works as expected, as long as pulseaudio is not present. I know there may be arguments to retain pulseaudio but until it can be made to work, it is an obsticle to an accessible system. I am concerned that unless the issues are solved by the release of buster, we are shipping a non-accessible system.
Re: loss of speech in speakup when switching between console and gui
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 : > >> 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/msg0.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
Re: loss of speech in speakup when switching between console and gui
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 : 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/msg0.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
Re: loss of speech in speakup when switching between console and gui
On 06/11/2018 12:51, john doe wrote: > Or using the terminal provided by the DE. Yes, but only it it is accessible,i.e. if there is still speech on the desktop. 0xD50202EF60C03EEA.asc Description: application/pgp-keys
Re: loss of speech in speakup when switching between console and gui
On 11/6/2018 12:23 PM, Didier Spaier wrote: > 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 ;) > Or using the terminal provided by the DE. -- John Doe
Re: loss of speech in speakup when switching between console and gui
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/msg0.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
Re: loss of speech in speakup when switching between console and gui
Keith Barrett, le dim. 04 nov. 2018 18:46:51 +, a ecrit: > On 04/11/18 18:36, Samuel Thibault wrote: > > Keith Barrett, le dim. 04 nov. 2018 18:32:41 +, a ecrit: > > > On 04/11/18 13:48, Didier Spaier wrote: > > > > On 04/11/2018 14:37, Keith Barrett wrote: > > > > > > > > > > > > > > > On 03/11/18 19:54, Didier Spaier wrote: > > > > > > Hello, > > > > > > > > > > > > I should have stated that this binary is a 64-bit one. > > > > > > > > > > > > Maybe you have a 32-bit system? > > > > > No, I have a 64-bit system. > > > > > Just thinking about it later, could it be a permissions/ownership > > > > > issue? > > > > i > > > > Just in case, try again, this time typing as root after having copied > > > > the file: > > > > chown root:root /usr/bin/espeakup > > > > chmod 755 /usr/bin/espeakup. > > > > > > > Success, it must have been permissions. > > > I have been switching between X and the console and so far, after a few > > > hours, no crashes at all. > > > > > > Thank you Didier for your efforts, a long standing issue solved for me, > > > can > > > we get the change included in debian? > > > > Not that simply since as I mentioned the setup that Didier uses is not > > the default setup configured by the pulseaudio package. That needs to be > > discussed with pulseaudio maintainers. > I thought that this was a different issue as I do not have pulseaudio on > this system and I still had the problem before Didier's modification and now > the problem is corrected. Yes, but the difference between Didier's version and the Debian version is a patch meant to fix the issue in the pulseaudio case without using Didier's pulseaudio setup. Samuel
Re: loss of speech in speakup when switching between console and gui
On 04/11/18 18:36, Samuel Thibault wrote: Keith Barrett, le dim. 04 nov. 2018 18:32:41 +, a ecrit: On 04/11/18 13:48, Didier Spaier wrote: On 04/11/2018 14:37, Keith Barrett wrote: On 03/11/18 19:54, Didier Spaier wrote: Hello, I should have stated that this binary is a 64-bit one. Maybe you have a 32-bit system? No, I have a 64-bit system. Just thinking about it later, could it be a permissions/ownership issue? i Just in case, try again, this time typing as root after having copied the file: chown root:root /usr/bin/espeakup chmod 755 /usr/bin/espeakup. Success, it must have been permissions. I have been switching between X and the console and so far, after a few hours, no crashes at all. Thank you Didier for your efforts, a long standing issue solved for me, can we get the change included in debian? Not that simply since as I mentioned the setup that Didier uses is not the default setup configured by the pulseaudio package. That needs to be discussed with pulseaudio maintainers. I thought that this was a different issue as I do not have pulseaudio on this system and I still had the problem before Didier's modification and now the problem is corrected. Samuel
Re: loss of speech in speakup when switching between console and gui
Keith Barrett, le dim. 04 nov. 2018 18:32:41 +, a ecrit: > On 04/11/18 13:48, Didier Spaier wrote: > > On 04/11/2018 14:37, Keith Barrett wrote: > > > > > > > > > On 03/11/18 19:54, Didier Spaier wrote: > > > > Hello, > > > > > > > > I should have stated that this binary is a 64-bit one. > > > > > > > > Maybe you have a 32-bit system? > > > No, I have a 64-bit system. > > > Just thinking about it later, could it be a permissions/ownership issue? > > i > > Just in case, try again, this time typing as root after having copied the > > file: > > chown root:root /usr/bin/espeakup > > chmod 755 /usr/bin/espeakup. > > > Success, it must have been permissions. > I have been switching between X and the console and so far, after a few > hours, no crashes at all. > > Thank you Didier for your efforts, a long standing issue solved for me, can > we get the change included in debian? Not that simply since as I mentioned the setup that Didier uses is not the default setup configured by the pulseaudio package. That needs to be discussed with pulseaudio maintainers. Samuel
Re: loss of speech in speakup when switching between console and gui
On 04/11/18 13:48, Didier Spaier wrote: On 04/11/2018 14:37, Keith Barrett wrote: On 03/11/18 19:54, Didier Spaier wrote: Hello, I should have stated that this binary is a 64-bit one. Maybe you have a 32-bit system? No, I have a 64-bit system. Just thinking about it later, could it be a permissions/ownership issue? i Just in case, try again, this time typing as root after having copied the file: chown root:root /usr/bin/espeakup chmod 755 /usr/bin/espeakup. Success, it must have been permissions. I have been switching between X and the console and so far, after a few hours, no crashes at all. Thank you Didier for your efforts, a long standing issue solved for me, can we get the change included in debian? Best, Didier On 03/11/2018 20:32, Keith Barrett wrote: Hello, Unfortunately, the modofication did not work, I copied it according to Didier's instructions but got no speech from speakup following the reboot. Reverting back to the original /usr/bin/espeakup got speech working again. Thanks Keith
Re: loss of speech in speakup when switching between console and gui
On 04/11/2018 14:37, Keith Barrett wrote: > > > On 03/11/18 19:54, Didier Spaier wrote: >> Hello, >> >> I should have stated that this binary is a 64-bit one. >> >> Maybe you have a 32-bit system? > No, I have a 64-bit system. > Just thinking about it later, could it be a permissions/ownership issue? i Just in case, try again, this time typing as root after having copied the file: chown root:root /usr/bin/espeakup chmod 755 /usr/bin/espeakup. >> Best, >> >> Didier >> >> On 03/11/2018 20:32, Keith Barrett wrote: >>> Hello, >>> >>> Unfortunately, the modofication did not work, I copied it according to >>> Didier's instructions but got no speech from speakup following the reboot. >>> >>> Reverting back to the original /usr/bin/espeakup got speech working again. >>> >>> Thanks >>> >>> Keith 0xD50202EF60C03EEA.asc Description: application/pgp-keys
Re: loss of speech in speakup when switching between console and gui
On 03/11/18 19:54, Didier Spaier wrote: Hello, I should have stated that this binary is a 64-bit one. Maybe you have a 32-bit system? No, I have a 64-bit system. Just thinking about it later, could it be a permissions/ownership issue? Best, Didier On 03/11/2018 20:32, Keith Barrett wrote: Hello, Unfortunately, the modofication did not work, I copied it according to Didier's instructions but got no speech from speakup following the reboot. Reverting back to the original /usr/bin/espeakup got speech working again. Thanks Keith
Re: loss of speech in speakup when switching between console and gui
Hello, I should have stated that this binary is a 64-bit one. Maybe you have a 32-bit system? Best, Didier On 03/11/2018 20:32, Keith Barrett wrote: > Hello, > > Unfortunately, the modofication did not work, I copied it according to > Didier's instructions but got no speech from speakup following the reboot. > > Reverting back to the original /usr/bin/espeakup got speech working again. > > Thanks > > Keith > > 0xD50202EF60C03EEA.asc Description: application/pgp-keys
Re: Re: loss of speech in speakup when switching between console and gui
Hello, Unfortunately, the modofication did not work, I copied it according to Didier's instructions but got no speech from speakup following the reboot. Reverting back to the original /usr/bin/espeakup got speech working again. Thanks Keith
Re: loss of speech in speakup when switching between console and gui
Hello, On 02/11/2018 17:33, Keith Barrett wrote: > It'd be interesting to check with the patch Unfortunately I was unable to properly rebuild a Debian package that provides an espeakup binary speaking after going back from graphical mode and sorry, I can't spend too much time on that. Instead, I provide a binary that you can try, which is the one I am using right now. I checked that it works as expected in my Debian Buster virtual machine. To get and install it at your own risks: wget http://slint.fr/testing/debian/espeakup wget http://slint.fr/testing/debian/espeakup.md5 md5sum -c espeakup.md5 su - # or use sudo cp /usr/bin/espeakup /usr/bin/espeakup.orig cp espeakup /usr/bin/ reboot You can double check that the file size is 23168 bytes and its md5sum is: 07bf31d91eaa47b7fbf1a7d08fde8511 Let us know how that goes. best regards, Didier 0xD50202EF60C03EEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: loss of speech in speakup when switching between console and gui
On 02/11/18 00: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/msg0.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 No, I think it is not as simple as that as I stated when I first reported the issue, pulseaudio is not installed on this system. 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? No, espeakup doesn't take the card again once anything in x uses it. I am using libao for orca is x and speakup does not get the card when switching back to a console. 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
Re: loss of speech in speakup when switching between console and gui
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 0xD50202EF60C03EEA.asc Description: application/pgp-keys
Re: loss of speech in speakup when switching between console and gui
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/msg0.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
Re: loss of speech in speakup when switching between console and gui
Hello, I just subscribed to this list to post this message. This message is an answer to the thread started by: https://lists.debian.org/debian-accessibility/2018/10/msg0.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" Let me say how I got there. I am the maintainer of the Slint distribution, based on Slackware, cf. http://slint.fr. In Slint we have no issue switching back an forth between console and graphical modes, thus Alex Arnaud suggested that I have a look at Debian testing. I installed Debian Buster in a VirtualBox VM today, switched to starting in console mode (systemctl set-default multi-user.target) then compared the alsa and pulseaudio settings with those of Slint64-14.2.1.1 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 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 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. I made these changes so that applications using pulseaudio and applications using alsa directly can nicely coexist, not stepping on each others toes. 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. I know, ugly hack but it was easier for me than to rebuild a Debian package (I am not a Debian user). 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 I don't know if the modifications I made are acceptable by the Debian authorities though ;) Last word: now when the desktop starts after "startx" I hear the messages triggered by startx, but then one can just redirect the output and standard error to some file, of review the patch audio-pause to allow enabling again espeakup when going back to a VT. 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. Best regards, Didier 0xD50202EF60C03EEA.asc Description: application/pgp-keys
Re: loss of speech in speakup when switching between console and gui
On 02/10/18 17:56, john doe wrote: On 10/2/2018 6:04 PM, Keith Barrett wrote: Is any one able to reproduce this? Debian buster up to date as of 01 October 2018. I am loosing speech in the console using speakup after switching back from the desktop. To reproduce, log in to the desktop and make sure orca is working. Then switch to one of the text consoles with control alt f4. Result for me is that speakup is no longer working. This happens more the 50 percent of the time. Thanks Keith This is a well known bug, that has been dealt with. The fix relies on multiple components though, as a consequence, it will take time to be fully implemented. See the archive of this list for more info. Sorry, I should have added, this is not the usual pulseaudio problem as that is purged from the system. This only started within the last few weeks. Credits goes primarily to "Samuel Thibault" for addressing this issue.
Re: loss of speech in speakup when switching between console and gui
On 10/2/2018 6:04 PM, Keith Barrett wrote: > Is any one able to reproduce this? > > Debian buster up to date as of 01 October 2018. > > I am loosing speech in the console using speakup after switching back > from the desktop. > To reproduce, log in to the desktop and make sure orca is working. > Then switch to one of the text consoles with control alt f4. > Result for me is that speakup is no longer working. > This happens more the 50 percent of the time. > > Thanks > > Keith > > > This is a well known bug, that has been dealt with. The fix relies on multiple components though, as a consequence, it will take time to be fully implemented. See the archive of this list for more info. Credits goes primarily to "Samuel Thibault" for addressing this issue. -- John Doe
