Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Christian Schoepplein, le lun. 28 mars 2022 12:48:02 +0200, a ecrit: > On Sun, May 09, 2021 at 10:18:23PM +0200, Samuel Thibault wrote: > >Christian Schoepplein, le dim. 09 mai 2021 21:29:27 +0200, a ecrit: > >> There are also other issues and problems with the output of brltty with > >> strange behaviour for empty or very long lines or for applications like > >> vim where a status line > > > >Note that there is a longstanding bug in libvte > > > >https://gitlab.gnome.org/GNOME/vte/issues/88 > > > >You can try the proposed patch to see whether that fixes issues. > > Maybe I'll try the patch but somewhere deep in my brain I remember that you > have build packages for Debian Bullseye with this patch included. Do I > remember this right and if yes, where can I find those packages? It's on deb https://people.debian.org/~sthibault/tmp/bullseye-tmp ./ > In the issue I can see no update :-(. Does this mean that there is no > progress yet? If there had been progress it would have been reported there. Samuel ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
On Tue, May 11, 2021 at 03:00:09PM +0200, Samuel Thibault wrote: >Christian Schoepplein, le mar. 11 mai 2021 14:46:45 +0200, a ecrit: >> Am 11.05.2021 um 14:42 schrieb Samuel Thibault: >> > Christian Schoepplein, le mar. 11 mai 2021 14:37:42 +0200, a ecrit: >> > > >> > > Am 11.05.2021 um 11:02 schrieb Samuel Thibault: >> > > > Christian Schoepplein, le mar. 11 mai 2021 09:04:26 +0200, a ecrit: >> > > > > It also turned out that many problems are gone when Mate terminal is >> > > > > used in >> > > > > fullscreen mode. >> > > > >> > > > Oh? That's surprising since it shouldn't be changing anything >> > > > concerning >> > > > the at-spi access to the terminal (except its width). Is this with >> > > > brltty 6.3? >> > > >> > > Yes, this is with brltty 6.3 on Debian Bullseye. >> > >> > Ah but this wasn't with the vte patch, right? >> >> Yes, this was with the unpatched version of libvte. There was no patched >> version of any package in use, just the packages from the last Debian >> Bullseye RC installer. > >Ok, then please try the libvte-2.91-0 package version 0.62.3-1+atspi >from this repository: > >deb https://people.debian.org/~sthibault/tmp/bullseye-tmp ./ I've installed the patched lib now and some quick tests showed no differences to the unpatched version :-(. Aditional to the doubble speech problem when two brltty instances are running there are the following issues when working with brltty in the Mate terminal: - With programs that have a constantly changing status bar or something similar the braille focus is set to this line. This happens in vim, in a tmux terminal, e.g.. It only happens when the braille focus is near this status bar, e.g. when a file is opend in vim and if you scrol down and the cursor is moving to the button of the screen. In a pure textbased environment I do not have this problem. - Sometimes the braille output is not refreshed allthough the content of the screen has changed. I have this very ofthen when using mutt via a ssh connection on my server. I use nano as editor and if I delete lines with Strg + k the deleted dows not disapear. They only way to get out of this situation and get a refreshed screen is to leave the editor and open the file again. This refreshing problems are the most anoying and they do occure not only in ssh session, but also when edeting local files, but I have the feeling that in ssh sessions they occure more ofthen. - When scrolling very fast through a screen with the arrow keys or the routing keys of my braille device (Handytech Braillestar 80) brltty is crashing. After such a crash the normal start message is displayed on the brailledevice for a few seconds then everything is working again. I still think to use Mate terminal for textbased work would be a nice solution to not have the trouble to setu up also speech for the pure textbased console and to not have to deal with all the pulseaudio based problems such a setup requires. For that reason I'd be really happy if the described problems can be solved. The biggest problems are not the doubble speech thing, but the the described problems with braille output. I've also tested to get brltty running in xterm or uxterm, but I had no success :-(. I've heard the starting sound of brltty and there are two brltty instances running, but I got no braille output. Also killing all brltty instances and only start one instance as root did help. Has anyone an idea how to start brltty in a xterm or uxterm environment? Cheers and thanks for all your support, Schoepp ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Am 11.05.2021 um 14:42 schrieb Samuel Thibault: Christian Schoepplein, le mar. 11 mai 2021 14:37:42 +0200, a ecrit: Am 11.05.2021 um 11:02 schrieb Samuel Thibault: Christian Schoepplein, le mar. 11 mai 2021 09:04:26 +0200, a ecrit: It also turned out that many problems are gone when Mate terminal is used in fullscreen mode. Oh? That's surprising since it shouldn't be changing anything concerning the at-spi access to the terminal (except its width). Is this with brltty 6.3? Yes, this is with brltty 6.3 on Debian Bullseye. Ah but this wasn't with the vte patch, right? Yes, this was with the unpatched version of libvte. There was no patched version of any package in use, just the packages from the last Debian Bullseye RC installer. Cheers, Schoepp ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Hi Samuel, Am 11.05.2021 um 11:02 schrieb Samuel Thibault: Christian Schoepplein, le mar. 11 mai 2021 09:04:26 +0200, a ecrit: It also turned out that many problems are gone when Mate terminal is used in fullscreen mode. Oh? That's surprising since it shouldn't be changing anything concerning the at-spi access to the terminal (except its width). Is this with brltty 6.3? Yes, this is with brltty 6.3 on Debian Bullseye. I started brltty in the Mate terminal like describe many times before: brltty -b ba -x a2 -N When the fullscreen mode is activated scroling behaviour is much better with brltty. Without fullscreen mode empty lines are not always displayed and sometimes the content of new lines is not shown when reading a text in textbased apps like nano, vi or w3m. I think this might have todo with the way very long lines are displayed in text mode application. Lets say you go through a text with very long lines in vi and you come to the end of the screen. If you go to the next line and this line is that long, that three lines on the screen are needed to display the whole content of this line, you only press one times arrow down to get into this new line with the computer or in the editor, but on the screen the content scrols three lines up to fully get displayed on the screen. If the fullscreen mode is used such conditions occure not that ofthen, because more content can be displayed. It seems to me that brltty has problems to deal with such conditions, buut I notice those problems only when I use brltty in the Mate terminal. In pure text environments such things do not occure. Cheers, Schoepp ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Christian Schoepplein, le mar. 11 mai 2021 14:46:45 +0200, a ecrit: > Am 11.05.2021 um 14:42 schrieb Samuel Thibault: > > Christian Schoepplein, le mar. 11 mai 2021 14:37:42 +0200, a ecrit: > > > > > > Am 11.05.2021 um 11:02 schrieb Samuel Thibault: > > > > Christian Schoepplein, le mar. 11 mai 2021 09:04:26 +0200, a ecrit: > > > > > It also turned out that many problems are gone when Mate terminal is > > > > > used in > > > > > fullscreen mode. > > > > > > > > Oh? That's surprising since it shouldn't be changing anything concerning > > > > the at-spi access to the terminal (except its width). Is this with > > > > brltty 6.3? > > > > > > Yes, this is with brltty 6.3 on Debian Bullseye. > > > > Ah but this wasn't with the vte patch, right? > > Yes, this was with the unpatched version of libvte. There was no patched > version of any package in use, just the packages from the last Debian > Bullseye RC installer. Ok, then please try the libvte-2.91-0 package version 0.62.3-1+atspi from this repository: deb https://people.debian.org/~sthibault/tmp/bullseye-tmp ./ You need to run sudo apt-key adv --recv-keys --keyserver keyring.debian.org 900CB024B67931D40F82304BD0178C767D069EE6 to get the key of the repository. Samuel signature.asc Description: PGP signature ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Christian Schoepplein, le mar. 11 mai 2021 14:37:42 +0200, a ecrit: > Hi Samuel, > > Am 11.05.2021 um 11:02 schrieb Samuel Thibault: > > Christian Schoepplein, le mar. 11 mai 2021 09:04:26 +0200, a ecrit: > > > It also turned out that many problems are gone when Mate terminal is used > > > in > > > fullscreen mode. > > > > Oh? That's surprising since it shouldn't be changing anything concerning > > the at-spi access to the terminal (except its width). Is this with > > brltty 6.3? > > Yes, this is with brltty 6.3 on Debian Bullseye. Ah but this wasn't with the vte patch, right? Samuel ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Am 11.05.2021 um 00:03 schrieb Samuel Thibault: But as I mentioned there is a known bug in vte, so it's probably not worth trying to describe your issues unless you are using the patch I proposed, which fixes the known bug (and use brltty 6.3 which also fixes some issues). OK, gogod to know. AFAIK Halim already compiled a new version of the lib with the mensioned patch included and so I'll also do. It also turned out that many problems are gone when Mate terminal is used in fullscreen mode. Now lets see if Dave can find a solution for the mensioned brltty problems. If there is a solution we will test further. Cheers, Schoepp ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
[quoted lines by Christian Schoepplein on 2021/05/11 at 09:04 +0200] >Now lets see if Dave can find a solution for the mensioned brltty problems. >If there is a solution we will test further. It always helps me when people are explicit. Do you mean the concurrent speech issue? -- I believe the Bible to be the very Word of God: http://Mielke.cc/bible/ Dave Mielke| 2213 Fox Crescent | WebHome: http://Mielke.cc/ EMail: d...@mielke.cc | Ottawa, Ontario | Twitter: @Dave_Mielke Phone: +1 613 726 0014 | Canada K2A 1H7 | ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Christian Schoepplein, le mar. 11 mai 2021 09:04:26 +0200, a ecrit: > It also turned out that many problems are gone when Mate terminal is used in > fullscreen mode. Oh? That's surprising since it shouldn't be changing anything concerning the at-spi access to the terminal (except its width). Is this with brltty 6.3? Samuel ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Dave Mielke, le dim. 09 mai 2021 15:45:27 -0400, a ecrit: > to tell Orca to ignore termiinal windows. I don't know if that's possible. Yes, this is possible by telling Orca to disable braille and speech when reading the terminal application. Samuel ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Christian Schoepplein, le dim. 09 mai 2021 21:29:27 +0200, a ecrit: > I can try to describe all my findings, but I don't know if my English is good > enough. Your english is clearly good enough :) But as I mentioned there is a known bug in vte, so it's probably not worth trying to describe your issues unless you are using the patch I proposed, which fixes the known bug (and use brltty 6.3 which also fixes some issues). Samuel ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Hello, Dave Mielke, le dim. 09 mai 2021 05:35:44 -0400, a ecrit: > [quoted lines by Samuel Thibault on 2021/05/09 at 11:13 +0200] > > if there is text to read, whatever the type it will return at least > > SQC_POOR, and speech will speak it, which is indeed what is expected > > when brltty is alone as a screen reader. > > Okay, so the real problem, then, is that we got rid of the old focus parameter Which focus parameter? Previously we would just not return any screen content for widget types that are not selected with the "type" atspi2 parameter. Samuel ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Hi Brian, Am 10.05.2021 um 02:08 schrieb Brian Buhrow: One way around the problem with a graphical terminal accessibility issues while still working in a graphical environment is to use a screen reader like brltty or Yasr in an instance of xterm. While brltty won't give you access to the rest of the graphical environment, it should give you full access to the xterm in which it's running. Then, you can use Orca for everything not a terminal plus Brltty for the xterm itself. I have no idea how such a setup could look like but I'd try it if you can tell a little bit more detailed what I have to to please. The advantage to use the Mate terminal would also be that you can use many of the features of a graphical environment. For example it would be very easy to copy and paste the content ofthe clipboard betwenn the two environments. Will that also be possible when using xterm to run brltty? Like said, I would giv it a try, but to be honest I'd be more happy if brltty would be able to run in a graphical terminal without the mensioned problems. Cheers, Schoepp ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Le 10/05/2021 à 09:12, Mario Lang a écrit : Didier Spaier writes: Le 09/05/2021 à 23:09, Samuel Thibault a écrit : Didier Spaier, le dim. 09 mai 2021 23:02:49 +0200, a ecrit: Still, this could be an issue for audiophiles, but they can use jack. Speech-based screen reading also requires very low latency to get snappy feedback. OK, then does anyone knows how to measure the latency increase? Latency in RT audio is mostly driven by buffer size. These buffer sizes vary greatly, depending on the software and hardware in use. JACK with a good soundcard can indeed go down to a buffer size of 64 frames or even lower. That makes for a fixed latency of around 2ms, depending on the sample rate. On the ohter end of the spectrum, carelessly written audio programs might go up to buffer sizes of up to 2048. Now latecy is more around 50ms, which is starting to get noticeable. However, I suspect there are several latencies adding up in the case of speech synthesis. It would indeed be worthwhile to investigate if some of these can be reduced. However, I think this would need some automated testing. To come back to your question, can you specify a little more clearly which increase you are refering to? I am speaking about latency that could occur if the sound is mixed first by pulseaudio then by dmix from alsa, following Aura's message: http://brltty.app/pipermail/brltty/2021-May/018429.html of which I paste the content below: On 2021-05-09 at 22:28 +0200, Didier Spaier wrote: > ### In Slint, we want to share audio resources between speech apps that > ### rely on alsa and other apps that rely on pulseaudio. > load-module module-alsa-sink device=dmix > load-module module-alsa-source device=dsnoop [--] > 1. I have been told that such a setting is not recommended. But nobody > so far > has been able to tell me why, and I have received zero complaint > from users > about it so far, as they get speech and braille in both console and > graphical > environments and can easily switch. The reason is latency. If the audio is mixed in software both on pulseaudio and alsa levels, the latency is unnecessarily high, and the processing will waste resources. Cheers, Didier ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Didier Spaier writes: > Le 09/05/2021 à 23:09, Samuel Thibault a écrit : >> Didier Spaier, le dim. 09 mai 2021 23:02:49 +0200, a ecrit: >>> Still, this could be an issue for audiophiles, but they can use jack. >> Speech-based screen reading also requires very low latency to get >> snappy >> feedback. > > OK, then does anyone knows how to measure the latency increase? Latency in RT audio is mostly driven by buffer size. These buffer sizes vary greatly, depending on the software and hardware in use. JACK with a good soundcard can indeed go down to a buffer size of 64 frames or even lower. That makes for a fixed latency of around 2ms, depending on the sample rate. On the ohter end of the spectrum, carelessly written audio programs might go up to buffer sizes of up to 2048. Now latecy is more around 50ms, which is starting to get noticeable. However, I suspect there are several latencies adding up in the case of speech synthesis. It would indeed be worthwhile to investigate if some of these can be reduced. However, I think this would need some automated testing. To come back to your question, can you specify a little more clearly which increase you are refering to? -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Hello. One way around the problem with a graphical terminal accessibility issues while still working in a graphical environment is to use a screen reader like brltty or Yasr in an instance of xterm. While brltty won't give you access to the rest of the graphical environment, it should give you full access to the xterm in which it's running. Then, you can use Orca for everything not a terminal plus Brltty for the xterm itself. -thanks -Brian ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
On Sun, May 09, 2021 at 09:08:34PM +0200, Didier Spaier wrote: > >I always wonder why people do in a graphical environment things more easily >done >in a console. Maybe just because that's what they are used to? Granted, there >are things that can't be done in console, but typing commands in a shell or >editing text files isn't among them, as far as I know. > I allways prefer the console if I have the tools to do the task I need or want to to in a textbased environment. And most of the things I have to do for work and also for myself private I can do in the console... The only reason I am looking for a solution to get brltty with speech support up and running in the Mate text terminal is that I am looking for a good altnerative to have a system with full screen reader support for the text console and also for a graphical environment. When I setup a new Debian for example I get a working Mate with speech and braille support, but I only get braille without speech support for the pure text console. If I like to enable speech support also for the text console, I have to do bad and ugly things to get it up and running. This bad and ugly things would be not longer necessary, if the Mate terminal can be used like a pure text based working environment. Setting up such a system would also be easy for Linux beginners and things would run much more stable. Ofcourse I could also configure my new Debian Bullseye system like I've configured thee other systems before, running pulseaudio as a systemwide daemon and do all those other stupid things to get speech in Mate and in the console, but if there is a a much better solution I'd like such a setup much more in future. Ciao, Schoepp ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
On Sun, May 09, 2021 at 11:13:03AM +0200, Samuel Thibault wrote: >Dave Mielke, le dim. 09 mai 2021 05:03:27 -0400, a ecrit: >> [quoted lines by halim.sa...@freenet.de on 2021/05/09 at 10:19 +0200] >> >> > The problem reported is not a speech only problem I think. >> >> Specifying a2:type=terminal screen driver parameter tells the AtSpi2 screen >> driver to only pay attention to terminal windows > >No, please reread tryRestartTerm, it only uses the typeFlags array to >determine the quality returned by the screen reader. If there is no text >to read it will return SCQ_NONE indeed since it has nothing to say. But >if there is text to read, whatever the type it will return at least >SQC_POOR, and speech will speak it, which is indeed what is expected >when brltty is alone as a screen reader. When I start brltty by typing brltty -b ba -x a2:type=terminal -N as a unpriviliged user in the mate terminal I get neither braille nor speech output :-(. I can see another brltty process has been started, but thats all. Are I am doing something wrong? Ciao, Schoepp ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Am 09.05.2021 um 12:10 schrieb Aura Kelloniemi: Isn't Orca's speech support for terminals better than BRLTTY's? I believe it is more featureful, though syncing the braille display with speech output is not possible, if Orca does the speaking. Exactly this is the problem. Speech and braille output is not allways in sync. Also some text applications behave strange when using them with a screen reader that is made for a graphical environment. For doing some fast and easy tasks Orca is enough as speech system, but for more complicated things its better to use also a speech system which is optimized for the console with brltty. Ciao, Schoepp ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Le 09/05/2021 à 23:24, Samuel Thibault a écrit : Didier Spaier, le dim. 09 mai 2021 23:13:18 +0200, a ecrit: Le 09/05/2021 à 23:09, Samuel Thibault a écrit : Didier Spaier, le dim. 09 mai 2021 23:02:49 +0200, a ecrit: Still, this could be an issue for audiophiles, but they can use jack. Speech-based screen reading also requires very low latency to get snappy feedback. OK, then does anyone knows how to measure the latency increase? A way I found easy was to tap control repeatedly, synchronize the tap with the feedback of Orca, and then count how many times a second I'm typing the key. Thanks. As speech-dispatcher in Slint by default sends it audio output to libao which sends it to alsa, I could compare the results with the ones I get sending the audio output to pulseaudio instead. Didier PS as an aside, with our default settings there should be no latency issue with Orca as pulseaudio doesn't come into play. Same for the console screen readers (e)speakup, speechd-up and fenrir. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Didier Spaier, le dim. 09 mai 2021 22:58:57 +0200, a ecrit: > Well initially I posted on linux-speakup, > I also posted here: > https://mail.gnome.org/archives/orca-list/2018-February/msg00143.html linux-speakup and orca are not pulseaudio-maintainer lists. > But you forwarded the suggestion in this message: > https://www.mail-archive.com/pkg-pulseaudio-devel@alioth-lists.debian.net/msg00172.html There was actually a reply, but no follow-up. Samuel ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Didier Spaier, le dim. 09 mai 2021 23:13:18 +0200, a ecrit: > Le 09/05/2021 à 23:09, Samuel Thibault a écrit : > > Didier Spaier, le dim. 09 mai 2021 23:02:49 +0200, a ecrit: > > > Still, this could be an issue for audiophiles, but they can use jack. > > > > Speech-based screen reading also requires very low latency to get snappy > > feedback. > > OK, then does anyone knows how to measure the latency increase? A way I found easy was to tap control repeatedly, synchronize the tap with the feedback of Orca, and then count how many times a second I'm typing the key. Samuel ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Le 09/05/2021 à 23:09, Samuel Thibault a écrit : Didier Spaier, le dim. 09 mai 2021 23:02:49 +0200, a ecrit: Still, this could be an issue for audiophiles, but they can use jack. Speech-based screen reading also requires very low latency to get snappy feedback. OK, then does anyone knows how to measure the latency increase? ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Didier Spaier, le dim. 09 mai 2021 23:02:49 +0200, a ecrit: > Still, this could be an issue for audiophiles, but they can use jack. Speech-based screen reading also requires very low latency to get snappy feedback. Samuel ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Le 09/05/2021 à 22:38, Aura Kelloniemi a écrit : On 2021-05-09 at 22:28 +0200, Didier Spaier wrote: > ### In Slint, we want to share audio resources between speech apps that > ### rely on alsa and other apps that rely on pulseaudio. > load-module module-alsa-sink device=dmix > load-module module-alsa-source device=dsnoop [--] > 1. I have been told that such a setting is not recommended. But nobody > so far > has been able to tell me why, and I have received zero complaint > from users > about it so far, as they get speech and braille in both console and > graphical > environments and can easily switch. The reason is latency. If the audio is mixed in software both on pulseaudio and alsa levels, the latency is unnecessarily high, and the processing will waste resources. I can understand this, but how big would be the latency increase? Still, this could be an issue for audiophiles, but they can use jack. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Le 09/05/2021 à 21:44, Christian Schoepplein a écrit : The only reason I am looking for a solution to get brltty with speech support up and running in the Mate text terminal is that I am looking for a good altnerative to have a system with full screen reader support for the text console and also for a graphical environment. When I setup a new Debian for example I get a working Mate with speech and braille support, but I only get braille without speech support for the pure text console. If I like to enable speech support also for the text console, I have to do bad and ugly things to get it up and running. This bad and ugly things would be not longer necessary, if the Mate terminal can be used like a pure text based working environment. Setting up such a system would also be easy for Linux beginners and things would run much more stable. Ofcourse I could also configure my new Debian Bullseye system like I've configured thee other systems before, running pulseaudio as a systemwide daemon and do all those other stupid things to get speech in Mate and in the console, but if there is a a much better solution I'd like such a setup much more in future. This issue comes from Debian default settings. In Slint that I maintain: 1. pulseaudio is only started on demand (when an application requires it) 2. pulseaudio is set to use the the dmix mixer, so ends all streams go to alsa through via this mixer. From our /etc/pulse/default.pa: ### In Slint, we want to share audio resources between speech apps that ### rely on alsa and other apps that rely on pulseaudio. load-module module-alsa-sink device=dmix load-module module-alsa-source device=dsnoop 3. We include nothing in alsa configuration that redirect streams to pulseaudio. All that not starting pulseaudio system wide. Caveats: 1. I have been told that such a setting is not recommended. But nobody so far has been able to tell me why, and I have received zero complaint from users about it so far, as they get speech and braille in both console and graphical environments and can easily switch. 2. I have tried several times to convince Debian contributors to do something similar, to no avail. Maybe I didn't use the right channel? Cheers, Didier ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Christian Schoepplein, le dim. 09 mai 2021 21:29:27 +0200, a ecrit: > There are also other issues and problems with the output of brltty with > strange behaviour for empty or very long lines or for applications like vim > where a status line Note that there is a longstanding bug in libvte https://gitlab.gnome.org/GNOME/vte/issues/88 You can try the proposed patch to see whether that fixes issues. Samuel ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
On 2021-05-09 at 21:08 +0200, Didier Spaier wrote: > > I always wonder why people do in a graphical environment things more > easily done > in a console. Maybe just because that's what they are used to? Granted, > there > are things that can't be done in console, but typing commands in a shell or > editing text files isn't among them, as far as I know. > There are two problems with the console: 1) Linux console is broken (and almost unmaintained). Its Unicode rendering is totally broken – it does not understand multi-column characters at all. Linux console does not support full Unicode fonts either, and is limited to 512 glyphs which is very little. Quite often I am in a situation where I need to start a graphical shell to be able to show something to a sighted person. Linux's keybaord support in the console is also very poor – no shifted arrow keys, and so forth. 2) Quite many things in a modern Linux system expect there to be a running desktop session. Notifications, for example require a windowing system. Some times power management features are only enabled if the user is logged into a graphical desktop. This could be fixed, in theory, but will not be because there are not enough blind developers who would implement and maintain the required changes (which may be huge). That's why I wish there was a graphical terminal emulator (and a window manager) which would be as accessible as the Linux console is right now. But, alas, there is no. Orca is slow, and the whole At-SPI2 protocol is flawed so that BRLTTY and Orca cannot make the graphical world sufficiently accessible in its current state. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
[quoted lines by Christian Schoepplein on 2021/05/09 at 21:29 +0200] >OK; then the only solution currently is to use an older brltty version if I >like to have a setup with speech support enabled for brltty in the Mate >terminal? Is this right? Maybe. Another possibility might be to tell Orca to ignore termiinal windows. I don't know if that's possible. Or, maybe, I have this backward. Is the problem that you're getting double speech when you are or aren't in a terminal window? >If this really is the only way to go, I don't know if it is worth the work. >There are also other issues and problems with the output of brltty with >strange behaviour for empty or very long lines or for applications like vim >where a status line is displayed which is constantly changing and with very >slow cursor routing. There were several problems with the AtSpi2 screen driver which have been fixed recently (in 6.2, I think). That might be a reason to upgrade even further. -- I believe the Bible to be the very Word of God: http://Mielke.cc/bible/ Dave Mielke| 2213 Fox Crescent | WebHome: http://Mielke.cc/ EMail: d...@mielke.cc | Ottawa, Ontario | Twitter: @Dave_Mielke Phone: +1 613 726 0014 | Canada K2A 1H7 | ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
[quoted lines by Christian Schoepplein on 2021/05/09 at 20:59 +0200] >When I start brltty by typing > >brltty -b ba -x a2:type=terminal -N The lowercase -x option is used to select the screen driver. For example: -xa2 The uppercase -X option is used to set a screen driver parameter. For example: -Xa2:type=terminal >as a unpriviliged user in the mate terminal I get neither braille nor speech >output :-(. Especially if you're using a USB braille device, you might want to try invoking brltty as root. A debug log would show what the actual problem is. For that, you can use the -L (uppercase) option to specify the log file. For example: -L/path/to/brltty.log -- I believe the Bible to be the very Word of God: http://Mielke.cc/bible/ Dave Mielke| 2213 Fox Crescent | WebHome: http://Mielke.cc/ EMail: d...@mielke.cc | Ottawa, Ontario | Twitter: @Dave_Mielke Phone: +1 613 726 0014 | Canada K2A 1H7 | ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Le 09/05/2021 à 20:41, Christian Schoepplein a écrit : Am 09.05.2021 um 12:10 schrieb Aura Kelloniemi: Isn't Orca's speech support for terminals better than BRLTTY's? I believe it is more featureful, though syncing the braille display with speech output is not possible, if Orca does the speaking. Exactly this is the problem. Speech and braille output is not allways in sync. Also some text applications behave strange when using them with a screen reader that is made for a graphical environment. For doing some fast and easy tasks Orca is enough as speech system, but for more complicated things its better to use also a speech system which is optimized for the console with brltty. Ciao, Schoepp I always wonder why people do in a graphical environment things more easily done in a console. Maybe just because that's what they are used to? Granted, there are things that can't be done in console, but typing commands in a shell or editing text files isn't among them, as far as I know. Cheers, Didier ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Hi Samul, Goodpoint :-). Then a keyboard command for enablig/disabling that behaviour would be useful. Regards Halim Am 09.05.2021 12:40 schrieb Samuel Thibault :halim.sa...@freenet.de, le dim. 09 mai 2021 12:33:30 +0200, a ecrit: > just for understanding the reason why should brltty with a2 screen driver read > widgets outside gnome / xfce /lxde /mate terminal? Just because it can, which can be useful in case orca crashes. Samuel ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
halim.sa...@freenet.de, le dim. 09 mai 2021 12:33:30 +0200, a ecrit: > just for understanding the reason why should brltty with a2 screen driver > read > widgets outside gnome / xfce /lxde /mate terminal? Just because it can, which can be useful in case orca crashes. Samuel ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Hi, just for understanding the reason why should brltty with a2 screen driver read widgets outside gnome / xfce /lxde /mate terminal? Does atspi provide information from which application the content is comming from? I would prefer orca to read all thing ousdide terminals and brltty with a2 screendriver read only things coming from the mentioned terminals. So we could use the best from both worlds. I hope Chris can give us feedback about brltty 6.3 and the type parameter. My brltty 6.0 does not read something outside terminals which is ok for me. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
On 2021-05-09 at 11:09 +0200, Samuel Thibault wrote: > But as I tried to explain in my first mail but apparently completely > failed: only makes the reading of other widgets *less* prioritized, > and not completely ignored. For braille that's fine enough since more > prioritized reading completely overrides the braille output. But > for speech these is no such thing as *overriding* priority, speech > dispatcher still reads everything that clients tell it, just in the > priority order. It currently does not have any way to know that there > are two screen readers, and only the messages of one of the two should > be actually spoken. Yes, ok, I did not read your message properly. Isn't Orca's speech support for terminals better than BRLTTY's? I believe it is more featureful, though syncing the braille display with speech output is not possible, if Orca does the speaking. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
[quoted lines by Samuel Thibault on 2021/05/09 at 11:13 +0200] >No, please reread tryRestartTerm, it only uses the typeFlags array to >determine the quality returned by the screen reader. If there is no text >to read it will return SCQ_NONE indeed since it has nothing to say. But >if there is text to read, whatever the type it will return at least >SQC_POOR, and speech will speak it, which is indeed what is expected >when brltty is alone as a screen reader. Okay, so the real problem, then, is that we got rid of the old focus parameter because we thought we no longer needed it. We didn't think of this case. The answer, therefore, might be to restore that parameter. -- I believe the Bible to be the very Word of God: http://Mielke.cc/bible/ Dave Mielke| 2213 Fox Crescent | WebHome: http://Mielke.cc/ EMail: d...@mielke.cc | Ottawa, Ontario | Twitter: @Dave_Mielke Phone: +1 613 726 0014 | Canada K2A 1H7 | ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
halim.sa...@freenet.de, le dim. 09 mai 2021 10:19:06 +0200, a ecrit: > The problem reported is not a speech only problem I think. It is, because for the braille case only one of the two screen readers get to show something, while for speech the two get sent to speech-dispatcher and spoken there. > running brltty with a2 screen driver should only produce speech and braille > when using it in the xfce/gnome/mate/lx... terminals. So that'd be the first solution I proposed in my very first mail. > Otherwise it might interfer with orcas braille output. It cannot, the priorities allow brlapi to know which of the two it has to display. That doesn't happen with speech-dispatcher. Samuel ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Aura Kelloniemi, le dim. 09 mai 2021 10:48:28 +0300, a ecrit: > On 2021-05-09 at 09:23 +0200, halim.sa...@freenet.de wrote: > > Yes, brltty should talk when a user enables speech. But It should _only_ > talk in xfce/mate/gnome terminals and not when > > using the graphical desktop. > > Does it help if you set > > screen-parameters a2:Type=terminal > > in your /etc/brltty.conf? That's already the default. But as I tried to explain in my first mail but apparently completely failed: only makes the reading of other widgets *less* prioritized, and not completely ignored. For braille that's fine enough since more prioritized reading completely overrides the braille output. But for speech these is no such thing as *overriding* priority, speech dispatcher still reads everything that clients tell it, just in the priority order. It currently does not have any way to know that there are two screen readers, and only the messages of one of the two should be actually spoken. Previously the braille part didn't have such overriding priority so we were making atspi2 completly shut up when the type is not the expected one. But then we had braille overriding priorities and thus we made atspi2 always return something, with a "quality" label to let braille know which priority to use. And thus speech starting always getting text to speech, which it now just does. Thus the three possibilities I mentioned. Samuel ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
[quoted lines by halim.sa...@freenet.de on 2021/05/09 at 09:23 +0200] > Yes, brltty should talk when a user enables speech. But It should > _only_ talk in xfce/mate/gnome terminals and not when using the > graphical desktop. I suppose that, strictly speaking, is a matter of user preference. Ideally, although there's still work to be done, there's no reason that the a2 screen driver shouldn't fully support the graphical environment. > On my Machine brltty 6.0 is in use in ubuntu 20.04 and that version of > brltty works as described. > I think the work on a2 driver in brltty 6.1 is the problem here. Have you tried speifying the option -Xa2:type=terminal? -- I believe the Bible to be the very Word of God: http://Mielke.cc/bible/ Dave Mielke| 2213 Fox Crescent | WebHome: http://Mielke.cc/ EMail: d...@mielke.cc | Ottawa, Ontario | Twitter: @Dave_Mielke Phone: +1 613 726 0014 | Canada K2A 1H7 | ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Hi On 2021-05-09 at 09:23 +0200, halim.sa...@freenet.de wrote: > Yes, brltty should talk when a user enables speech. But It should _only_ > talk in xfce/mate/gnome terminals and not when > using the graphical desktop. Does it help if you set screen-parameters a2:Type=terminal in your /etc/brltty.conf? -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Hi Dave, Yes, brltty should talk when a user enables speech. But It should _only_ talk in xfce/mate/gnome terminals and not when using the graphical desktop. On my Machine brltty 6.0 is in use in ubuntu 20.04 and that version of brltty works as described. I think the work on a2 driver in brltty 6.1 is the problem here. HTH. Halim Sahin Am 09.05.2021 08:22 schrieb Dave Mielke :[quoted lines by Samuel Thibault on 2021/05/08 at 20:29 +0200] >From: Christian Schoepplein >To: debian-accessibil...@lists.debian.org >Subject: Problems when using brltty in the terminal >Date: Sat, 8 May 2021 16:20:35 +0200 > >3. Edited the file /etc/X11/Xsession.d/90xbrlapi and removed the "-s no" parameter for the startcommand of brltty. ... >But it seems, and that is totaly not understandable for me, that the brltty also is able to read things in ghe graphical environment. Wehn I open the application menu for example with Alt + F1 the entries are also outputed by the speech system, when no Orca and also only the brltty in the terminal with speech support is running. I'm not fully understanding, but that's probably because I don't work within the graphical environment. What I'm not understanding is that he enables brltty speech and then wonders why its speaking. It seems that both brltty and orca are speaking, but, if so, why did he enable brltty speech? -- I believe the Bible to be the very Word of God: http://Mielke.cc/bible/ Dave Mielke | 2213 Fox Crescent | WebHome: http://Mielke.cc/ EMail: d...@mielke.cc | Ottawa, Ontario | Twitter: @Dave_Mielke Phone: +1 613 726 0014 | Canada K2A 1H7 | ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
[quoted lines by Samuel Thibault on 2021/05/08 at 20:29 +0200] >From: Christian Schoepplein >To: debian-accessibil...@lists.debian.org >Subject: Problems when using brltty in the terminal >Date: Sat, 8 May 2021 16:20:35 +0200 > >3. Edited the file /etc/X11/Xsession.d/90xbrlapi and removed the "-s no" >parameter for the startcommand of brltty. ... >But it seems, and that is totaly not understandable for me, that the brltty >also is able to read things in ghe graphical environment. Wehn I open the >application menu for example with Alt + F1 the entries are also outputed by >the speech system, when no Orca and also only the brltty in the terminal with >speech support is running. I'm not fully understanding, but that's probably because I don't work within the graphical environment. What I'm not understanding is that he enables brltty speech and then wonders why its speaking. It seems that both brltty and orca are speaking, but, if so, why did he enable brltty speech? -- I believe the Bible to be the very Word of God: http://Mielke.cc/bible/ Dave Mielke| 2213 Fox Crescent | WebHome: http://Mielke.cc/ EMail: d...@mielke.cc | Ottawa, Ontario | Twitter: @Dave_Mielke Phone: +1 613 726 0014 | Canada K2A 1H7 | ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
