Sound Card selection at boot
Hello, Since updating bullseye to bookworm, the same sound card is not being used at boot time. There are two sound cards in this machine and before the update, one card was always used when the system started so speech was reliable. Since the update to Bookworm, the card selection is random. I can get sound back by plugging the speakers in to the other card. System is debian bookworm, pulseaudio is not installed using mate desktop. Keith
Re: Graphics (braille) embossing
Hello, In case it helps, last time I looked at this, both margins and papersize set in cupps were ignored. Using an index basic d embosser. On 22/05/2020 14:33, Sebastian Humenda wrote: Hi Samuel I am warming up this rather old thread, since I finally got around to experiment a bit. Sebastian Humenda, le jeu. 20 févr. 2020 08:39:04 +, a ecrit: There is software for Windows, not part of the standard embosser driver, which can print SVG and black/white, 50 DPI pictures, so I was wondering whether somebody did something similar on Debian? Yes, I did :) See the Braille Embossing section of /usr/share/doc/cups-filters/README.gz Thanks for implementing this :-). Where is the upstream source of this file? I found the set up to be astonishingly simple, not remotely comparable with the set up on Windows that I needed to do :-(. Samuel Thibault schrieb am 20.02.2020, 23:11 +0100: Sebastian Humenda, le jeu. 20 févr. 2020 22:17:56 +0100, a ecrit: How good is the interpretation of the layout? It's simply liblouis. Ok, so I'll need to take a look there. The first results with the embosser looked strange, a mixture of English and German grade 2 braille... How would I adjust settings such as the language to emboss? As usual with cups, in the http://localhost:631 web interface, or on the fly on the command line. I had the impression that it simply ignored settings that I have set in the printer tab of my text editor (pluma), but I need a more reliable way to test this. When I print from pluma, it always inserts the path to the file at the top of the printed result, any clue why? After a while, printing stopped working. I investigated the print command that cups showed: ile2brl -p -Chyphenate=yes -CliteraryTextTable=en-us-brf.dis,en-GB-g2.ctb,de-g2.ctb,de-de-comp8.ctb,braille-patterns.cti -CinputTextEncoding=UTF8 -CbraillePages=yes -CbraillePageNumberAt=bottom -CpageNumberBottomSeparateLine=yes -CprintPages=no -CpageSeparator=no -CpageSeparatorNumber=yes -CcontinuePages=no -CcellsPerLine=27 -ClinesPerPage=26 | | addmargins First I figured out that liblouisxml-data was missing, should this be added as a dependency? Second, there seems to be no addmargins in the Debian archive, is this an oversight? Last but not least, there's a double pipe, I suppose dash doesn't like this. When I pipe "hi" into the above text (with addmargins removed) I get an error like pasted below this e-mail. Any idea what is going wrong? I'd need to try it out myself. I'd think that curves are much more precise with ~50 DPI, Yes, but I'm unsure one can feel the difference that much. I have tried to plot a diagram that has two close lines and it shows as one line in the printed version. It is better when using Gnuplot with its ASCII output module. I am not sure whether the issue is the missing resolution or the conversion beforehand. Thanks Sebastian === Begin read_configuration_file found table /usr/share/liblouis/tables/en-us-g2.ctb found table /usr/share/liblouis/tables/en-us-g1.ctb found table /usr/share/liblouis/tables/chardefs.cti found table /usr/share/liblouis/tables/loweredDigits6Dots.uti found table /usr/share/liblouis/tables/latinLetterDef8Dots.uti found table /usr/share/liblouis/tables/litdigits6Dots.uti found table /usr/share/liblouis/tables/braille-patterns.cti found table /usr/share/liblouis/tables/en-us-g1.ctb found table /usr/share/liblouis/tables/chardefs.cti found table /usr/share/liblouis/tables/loweredDigits6Dots.uti found table /usr/share/liblouis/tables/latinLetterDef8Dots.uti found table /usr/share/liblouis/tables/litdigits6Dots.uti found table /usr/share/liblouis/tables/braille-patterns.cti found table /usr/share/liblouis/tables/en-us-comp8.ctb found table /usr/share/liblouis/tables/loweredDigits6Dots.uti found table /usr/share/liblouis/tables/latinLetterDef8Dots.uti Cannot resolve table 'nemeth.ctb' 1 errors found. nemeth.ctb could not be compiled liblouisutdml.ini:38: Table 'nemeth.ctb' cannot be found. liblouisutdml.ini:38: invalid mathexprTableName found table /usr/share/liblouis/tables/compress.cti found table /usr/share/liblouis/tables/en-us-g2.ctb found table /usr/share/liblouis/tables/en-us-g1.ctb found table /usr/share/liblouis/tables/chardefs.cti found table /usr/share/liblouis/tables/loweredDigits6Dots.uti found table /usr/share/liblouis/tables/latinLetterDef8Dots.uti found table /usr/share/liblouis/tables/litdigits6Dots.uti found table /usr/share/liblouis/tables/braille-patterns.cti Cannot resolve table 'nemeth.ctb' 1 errors found. nemeth.ctb could not be compiled preferences.cfg:108: Table 'nemeth.ctb' cannot be found. preferences.cfg:108: invalid mathexprTableName found table /usr/share/liblouis/tables/en-us-brf.dis found table /usr/share/liblouis/tables/en-GB-g2.ctb found table /usr/share/liblouis/tables/de-g2.ctb found table /usr/share/liblouis/tables/de-de-comp8.ctb found table /usr/share/liblouis/tables/braille-patterns.cti found table
Kenwood tm-d710ge
Hello, I am taking delivery of a Kenwood tm-d710ge this week. Does any one on here have a panel description or an accessible manual? Many thanks Keith gw4nby
Re: sound card ordering
On 23/08/2019 17:45, Keith Barrett wrote: On 23/08/2019 17:13, Didier Spaier wrote: Helo, On 23/08/2019 17:35, Keith Barrett wrote: On 23/08/2019 00:08, Didier Spaier wrote: Hello, Just to be sure, please attach /etc/modprobe.d/soundcards.conf to your next post OK, here it is: options index=0 options index=1 It should be: options snd_hda_intel index=0 options snd_oxygen index=1 Thank you, I have made the change but still the order is random. Should I add the lines to /etc/modprobe.d/local.conf which already exists? I know I might be going off track here but, it seems that the file /etc/modprobe.d/local.conf is not doing anything either. That file contains the line options speakup synth=soft and was created by the debian installer. However, commenting the line out, and speakup still starts so the soft synth module must be being loaded from somewhere else. I now have the second sound card working so by plugging the speakers in to the other card, I can still get speech but it would be nice to have this working properly. Only other thing I can think of is whether the /etc/modprobe.d directory is being overridden by some files in another place. I do appreciate your taking the trouble to help with this, thank you again! Best regards, Didier And type as root: chmod 644 /etc/modprobe.d/soundcards.conf although it has probably these permissions already.tried that but no change. One more thought, can there be more than one .conf file in /etc/modprobe.d as I have one called local.conf as well which loads the speakup_soft module? Best, Didier On 22/08/2019 23:05, Keith Barrett wrote: On 21/08/2019 19:10, Didier Spaier wrote: Hello, replying in line (this also answers your more recent private email): On 20/08/2019 23:23, Keith Barrett wrote: So I have now specified MID in /etc/default/espeakup and that does cause espeakup to start with speech each time the system boots. However, the card ordering is still very random which means that although espeakup is always working, if the cards load so that MID is not 0, I get no other system sounds and orca does not work in the gui. So, I suppose what I should be trying to achieve is to cause the sound cards to retain their correct numbering so that all sound works following a reboot. To do this, type: cat /proc/asound/modules 0 snd_oxygen 1 snd_hda_intel You will probably get two lines in the output (one for each card), with the card number on the left an the associated kernel module name on the right of each line. Just create a file as root a file /etc/modprobe.d/soundcards.conf with two lines: options index=0 options index=1 replacing by the name of the module for the card you want to be loaded first and by the other card's module name, both spelled exactly as in the output of: cat /proc/asound/modules. This way, the cards' order will stay the same across reboots. Unfortunately, this has not worked, I have created /etc/modprobe.d/soundcards.conf but there has been no change. The only thing I can think of it whether I may need to change the permissions of soundcards.conf? Thank you for your help, it is appreciated. Best, Didier PS the name of the file in /etc/modprobe.d doesn't matter, but it has to end in .conf
Re: sound card ordering
On 23/08/2019 17:13, Didier Spaier wrote: Helo, On 23/08/2019 17:35, Keith Barrett wrote: On 23/08/2019 00:08, Didier Spaier wrote: Hello, Just to be sure, please attach /etc/modprobe.d/soundcards.conf to your next post OK, here it is: options index=0 options index=1 It should be: options snd_hda_intel index=0 options snd_oxygen index=1 Thank you, I have made the change but still the order is random. Should I add the lines to /etc/modprobe.d/local.conf which already exists? Only other thing I can think of is whether the /etc/modprobe.d directory is being overridden by some files in another place. I do appreciate your taking the trouble to help with this, thank you again! Best regards, Didier And type as root: chmod 644 /etc/modprobe.d/soundcards.conf although it has probably these permissions already.tried that but no change. One more thought, can there be more than one .conf file in /etc/modprobe.d as I have one called local.conf as well which loads the speakup_soft module? Best, Didier On 22/08/2019 23:05, Keith Barrett wrote: On 21/08/2019 19:10, Didier Spaier wrote: Hello, replying in line (this also answers your more recent private email): On 20/08/2019 23:23, Keith Barrett wrote: So I have now specified MID in /etc/default/espeakup and that does cause espeakup to start with speech each time the system boots. However, the card ordering is still very random which means that although espeakup is always working, if the cards load so that MID is not 0, I get no other system sounds and orca does not work in the gui. So, I suppose what I should be trying to achieve is to cause the sound cards to retain their correct numbering so that all sound works following a reboot. To do this, type: cat /proc/asound/modules 0 snd_oxygen 1 snd_hda_intel You will probably get two lines in the output (one for each card), with the card number on the left an the associated kernel module name on the right of each line. Just create a file as root a file /etc/modprobe.d/soundcards.conf with two lines: options index=0 options index=1 replacing by the name of the module for the card you want to be loaded first and by the other card's module name, both spelled exactly as in the output of: cat /proc/asound/modules. This way, the cards' order will stay the same across reboots. Unfortunately, this has not worked, I have created /etc/modprobe.d/soundcards.conf but there has been no change. The only thing I can think of it whether I may need to change the permissions of soundcards.conf? Thank you for your help, it is appreciated. Best, Didier PS the name of the file in /etc/modprobe.d doesn't matter, but it has to end in .conf
Re: sound card ordering
On 23/08/2019 00:08, Didier Spaier wrote: Hello, Just to be sure, please attach /etc/modprobe.d/soundcards.conf to your next post OK, here it is: options index=0 options index=1 And type as root: chmod 644 /etc/modprobe.d/soundcards.conf although it has probably these permissions already.tried that but no change. One more thought, can there be more than one .conf file in /etc/modprobe.d as I have one called local.conf as well which loads the speakup_soft module? Best, Didier On 22/08/2019 23:05, Keith Barrett wrote: On 21/08/2019 19:10, Didier Spaier wrote: Hello, replying in line (this also answers your more recent private email): On 20/08/2019 23:23, Keith Barrett wrote: So I have now specified MID in /etc/default/espeakup and that does cause espeakup to start with speech each time the system boots. However, the card ordering is still very random which means that although espeakup is always working, if the cards load so that MID is not 0, I get no other system sounds and orca does not work in the gui. So, I suppose what I should be trying to achieve is to cause the sound cards to retain their correct numbering so that all sound works following a reboot. To do this, type: cat /proc/asound/modules 0 snd_oxygen 1 snd_hda_intel You will probably get two lines in the output (one for each card), with the card number on the left an the associated kernel module name on the right of each line. Just create a file as root a file /etc/modprobe.d/soundcards.conf with two lines: options index=0 options index=1 replacing by the name of the module for the card you want to be loaded first and by the other card's module name, both spelled exactly as in the output of: cat /proc/asound/modules. This way, the cards' order will stay the same across reboots. Unfortunately, this has not worked, I have created /etc/modprobe.d/soundcards.conf but there has been no change. The only thing I can think of it whether I may need to change the permissions of soundcards.conf? Thank you for your help, it is appreciated. Best, Didier PS the name of the file in /etc/modprobe.d doesn't matter, but it has to end in .conf
Re: sound card ordering
On 20/08/2019 21:47, Samuel Thibault wrote: Hello, Keith Barrett, le lun. 19 août 2019 15:55:01 +0100, a ecrit: On 18/08/2019 21:08, Samuel Thibault wrote: Keith Barrett, le dim. 18 août 2019 20:30:50 +0100, a ecrit: Interesting, I have not modified /etc/default/espeakup but it does not seem to specify a card: ALSA_CARD="" Oh? were you installing with speakup enabled during installation? Yes I was Uh, that's odd then. Was the VOICE variable also not set? Yes, VOICE=en unless it was because the installer only detected one of the cards? No, in my tests even in that case it would write the ID. That's where specifying either MID or DGX instead of 0/1 allows to avoid relying on the ordering. OK, thank you, so do I just need to specify in /etc/default/espeakup Yes, that's it! Sorry for the noise but I have probably been going about this in the wrong way. So I have now specified MID in /etc/default/espeakup and that does cause espeakup to start with speech each time the system boots. However, the card ordering is still very random which means that although espeakup is always working, if the cards load so that MID is not 0, I get no other system sounds and orca does not work in the gui. So, I suppose what I should be trying to achieve is to cause the sound cards to retain their correct numbering so that all sound works following a reboot. Samuel
Re: sound card ordering
On 18/08/2019 21:08, Samuel Thibault wrote: Keith Barrett, le dim. 18 août 2019 20:30:50 +0100, a ecrit: On 18/08/2019 18:12, Samuel Thibault wrote: Keith Barrett, le sam. 17 août 2019 13:41:14 +0100, a ecrit: There are two sound cards in the system but only one was detected when I installed buster. When the system starts, the card ordering is not reliable so on occasions the non working asus card is card 0 hence producing no speech output. I'm surprised: what ALSA_CARD do you have in /etc/default/espeakup? Interesting, I have not modified /etc/default/espeakup but it does not seem to specify a card: ALSA_CARD="" Oh? were you installing with speakup enabled during installation? Yes I was so I am not sure why a default card was not written to /etc/default/espeakup unless it was because the installer only detected one of the cards? Is this known and how can I force the onboard card to be always card 0? Normally the installer uses named identifiers instead of numbered identifiers: in /proc/asounc/cards you can find e.g. Here is /proc/asound/cards 0 [MID]: HDA-Intel - HDA Intel MID HDA Intel MID at 0xfbff8000 irq 31 1 [DGX]: CMI8786 - Xonar DGX C-Media Oxygen HD Audio at 0xce00, irq 19 I am not sure that this order is retained when it boots in the non-working state. That's where specifying either MID or DGX instead of 0/1 allows to avoid relying on the ordering. OK, thank you, so do I just need to specify in /etc/default/espeakup or should it be somewhere else? Samuel
Re: sound card ordering
On 18/08/2019 18:12, Samuel Thibault wrote: Hello, Keith Barrett, le sam. 17 août 2019 13:41:14 +0100, a ecrit: There are two sound cards in the system but only one was detected when I installed buster. When the system starts, the card ordering is not reliable so on occasions the non working asus card is card 0 hence producing no speech output. I'm surprised: what ALSA_CARD do you have in /etc/default/espeakup? Interesting, I have not modified /etc/default/espeakup but it does not seem to specify a card: ALSA_CARD="" Is this known and how can I force the onboard card to be always card 0? Normally the installer uses named identifiers instead of numbered identifiers: in /proc/asounc/cards you can find e.g. Here is /proc/asound/cards 0 [MID]: HDA-Intel - HDA Intel MID HDA Intel MID at 0xfbff8000 irq 31 1 [DGX]: CMI8786 - Xonar DGX C-Media Oxygen HD Audio at 0xce00, irq 19 I am not sure that this order is retained when it boots in the non-working state. 0 [PCH]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xdc428000 irq 143 You would have "PCH" in /etc/default/espeakup's ALSA_CARD instead of 0, to thus have a more reliable specifier. Samuel
sound card ordering
Hello, Debian bullseye upgraded from buster amd64. Pulseaudio removed and purged. There are two sound cards in the system but only one was detected when I installed buster. When the system starts, the card ordering is not reliable so on occasions the non working asus card is card 0 hence producing no speech output. I think it may be down to the order of module loading as creating /;etc/asound.conf does not appear to work. Is this known and how can I force the onboard card to be always card 0? Thanks Keith
speakup screen review not working after system comes out of power saving
Hello, Can any one else reproduce? Debian buster amd64, updated on 12th June 2019. If system is not used and goes in to power saving mode, i.e. drive not spinning, after pressing power button and logging back in, the screen review keys in speakup are not working. Also, arrow keys are not reading content in a file opened in nano. Thanks Keith
Re: index braille embosser
On 08/04/19 16:59, Samuel Thibault wrote: Keith Barrett, le lun. 08 avril 2019 16:31:22 +0100, a ecrit: I am attaching the full output of the command and the temp file that resulted from it. I have not sent it to the list as it is long Being long is not a problem :) and contains the file which I was brailling. That is however more sensitive indeed, you can however drop that part when posting to the list. It gave me an access denied if I attempted it as a user so I had to become root before it worked, I am not sure if that is significant. That might be. One thing, the paper size did not seem to correspond with what I have set in cups, unless it is just displayed differently. That's more concerning is that there isn't the error message you mentioned previously. DEBUG: Attribute DefaultPageSize is '110x120' DEBUG: Default PageSize is '110x120' That page size is indeed supported. Well, I take it you must be talking about using the custom option to get that page size because my options in cups are: US legal, US letter, A3, a4, a4 tractor feed, a5, 11 x 11.5 11 x 12, 11 x 17, 11.5 x 11, 12 x 12, custom. What had you set instead? Are you properly providing the .ppd file of the printer you are normally using Yes, I believe I am providing the correct ppd file, right, so in cups the media size is set at 11 X 12. for embossing? Samuel
Re: index braille embosser
On 07/04/19 22:56, Samuel Thibault wrote: Keith Barrett, le dim. 07 avril 2019 22:02:53 +0100, a ecrit: On 07/04/19 20:44, Samuel Thibault wrote: Keith Barrett, le dim. 07 avril 2019 13:10:07 +0100, a ecrit: On 06/04/2019 23:50, Samuel Thibault wrote: All I can find in the cupps log is lots of the following:- Unrecognized control character in .brf file. How do you feed input to cups exactly? So far, I have used "Control p" and selected the index printer from within plumer text editor, should I be doing something different? The problem with printing from applications is that for now applications send a pdf to cups, which then can only use pdftotext to produce a text document for the embosser, with the obvious issues. I still have to convince cups people that applications should be given the choice of just sending their document. In the meanwhile, you can just directly submit your document from the command line: lp foo.txt OK, thank you for this. Now I have a top margin as expected but the line lengths seem to be wrong. It appears that there is an equal margin on each side of the page but every second line is cut short with only one or two words contained on it. I wonder if I need to change the paper size in cups? It looks like the paper size is too large and the embosser has to put the overflowed text on its own line indeed. Can you tell me if the braille file is stored anywhere to see if the line breaks corresponjd with the braille output? You can use /usr/sbin/cupsfilter -P /etc/cups/ppd/your-printer.ppd -m application/vnd.cups-brf yourfile.txt > /tmp/test.brf OK, looks like something is not right here:- error: unknown page size stopped with status 1 Also, as a point of interest, can I send anything other than text files using the lp command? See /usr/share/doc/cups-filters/README.gz: lp file.html lp file.odt lp file.doc lp file.rtf lp file.docx lp file.pdf Samuel
Re: index braille embosser
On 07/04/19 22:02, Keith Barrett wrote: On 07/04/19 20:44, Samuel Thibault wrote: Hello, Keith Barrett, le dim. 07 avril 2019 13:10:07 +0100, a ecrit: On 06/04/2019 23:50, Samuel Thibault wrote: Hello, Keith Barrett, le sam. 06 avril 2019 19:00:22 +0100, a ecrit: The embosser is recognized by cupps which correctly identified it's version. The first side of the first page works although the embossing begins at the very top edge, ignoring the top margin. Do you mean the top margin you configured on the embosser or in cups? In cups, I presume that the settings in cups would override anything set on the embosser? With the Index driver, yes. All I can find in the cupps log is lots of the following:- Unrecognized control character in .brf file. How do you feed input to cups exactly? So far, I have used "Control p" and selected the index printer from within plumer text editor, should I be doing something different? The problem with printing from applications is that for now applications send a pdf to cups, which then can only use pdftotext to produce a text document for the embosser, with the obvious issues. I still have to convince cups people that applications should be given the choice of just sending their document. In the meanwhile, you can just directly submit your document from the command line: lp foo.txt OK, thank you for this. Now I have a top margin as expected but the line lengths seem to be wrong. It appears that there is an equal margin on each side of the page but every second line is cut short with only one or two words contained on it. I wonder if I need to change the paper size in cups? I will carry out some more tests to see if I can find out what is going on. Can you tell me if the braille file is stored anywhere to see if the line breaks corresponjd with the braille output? I have spent some time testing and my findings are:- 1 When setting the top margin in cups, it seems to be ignored or inaccurate. I have it set to 1 inch but the braille is extremely close to the top of the page or some times runs off the top of the paper. This is using tractor feed paper so I am ruling out paper alignment at this stage. 2 Line length seems to be inconsistent. I have compared a braille document embossed on a pc running windows and duxbery embossing software and the line length appears to be 42 characters including spaces. On cups, the line length is 38 characters and the remainder are transposed to the next line so we have a line with 38 characters and the following line has 4 to 5 characters and so on. The lines break in the middle of a wor 3 As far as I can gather, changing the paper size in cups does not affect the line length. I only have one size of tractor feed and I would expect changing the paper size in cups would determine the length of the lines but it does not seem to be the case. The file I am testing with was created in libre office and saved as a plain text file. I would really like to get this working if possible so thank you for your help. Also, as a point of interest, can I send anything other than text files using the lp command? Thanks Keith Samuel
Re: index braille embosser
On 07/04/19 20:44, Samuel Thibault wrote: Hello, Keith Barrett, le dim. 07 avril 2019 13:10:07 +0100, a ecrit: On 06/04/2019 23:50, Samuel Thibault wrote: Hello, Keith Barrett, le sam. 06 avril 2019 19:00:22 +0100, a ecrit: The embosser is recognized by cupps which correctly identified it's version. The first side of the first page works although the embossing begins at the very top edge, ignoring the top margin. Do you mean the top margin you configured on the embosser or in cups? In cups, I presume that the settings in cups would override anything set on the embosser? With the Index driver, yes. All I can find in the cupps log is lots of the following:- Unrecognized control character in .brf file. How do you feed input to cups exactly? So far, I have used "Control p" and selected the index printer from within plumer text editor, should I be doing something different? The problem with printing from applications is that for now applications send a pdf to cups, which then can only use pdftotext to produce a text document for the embosser, with the obvious issues. I still have to convince cups people that applications should be given the choice of just sending their document. In the meanwhile, you can just directly submit your document from the command line: lp foo.txt OK, thank you for this. Now I have a top margin as expected but the line lengths seem to be wrong. It appears that there is an equal margin on each side of the page but every second line is cut short with only one or two words contained on it. I wonder if I need to change the paper size in cups? I will carry out some more tests to see if I can find out what is going on. Can you tell me if the braille file is stored anywhere to see if the line breaks corresponjd with the braille output? Also, as a point of interest, can I send anything other than text files using the lp command? Thanks Keith Samuel
Re: index braille embosser
On 06/04/2019 23:50, Samuel Thibault wrote: Hello, Keith Barrett, le sam. 06 avril 2019 19:00:22 +0100, a ecrit: The embosser is recognized by cupps which correctly identified it's version. The first side of the first page works although the embossing begins at the very top edge, ignoring the top margin. Do you mean the top margin you configured on the embosser or in cups? In cups, I presume that the settings in cups would override anything set on the embosser? All I can find in the cupps log is lots of the following:- Unrecognized control character in .brf file. How do you feed input to cups exactly? So far, I have used "Control p" and selected the index printer from within plumer text editor, should I be doing something different? If any one has managed to get this combination working, would appreciate some pointers. Jason White, le sam. 06 avril 2019 16:55:28 -0400, a ecrit: I don't know how to configure Cups correctly for a braille embosser, This is documented in /usr/share/doc/cups-filters/README.gz , BRAILLE EMBOSSING section. Samuel
index braille embosser
Hello, Debian buster amd64, index basic D embosser with 12.2.0 firmware. I am having an issue with paper size and margins. The embosser is recognized by cupps which correctly identified it's version. The first side of the first page works although the embossing begins at the very top edge, ignoring the top margin. The embossing ends half way down the second side of the page. All I can find in the cupps log is lots of the following:- Unrecognized control character in .brf file. If any one has managed to get this combination working, would appreciate some pointers. Thanks and regards Keith
Re: Request for CLI espeak Install to have needed CLI programs for blind.
On 10/12/2018 17:40, D.J.J. Ring, Jr. wrote: That isn't what I said. I was asking that a working CLI Installation be one of the options. I would also like this. I think having wifi configured during the install would solve most of the issues here. There is still a lot of effort needed to get a working CLI system with basic console programs. It would greatly help those who need or want keyboard centered system. I forgive you for telling me what I meant, and then being wrong about it. The person has been using CLI systems for 20 years. Best regards, David On Mon, Dec 10, 2018, 11:53 john doe On 12/10/2018 5:25 PM, D.J.J. Ring, Jr. wrote: Hello, Is there someone to ask to see if we can obtain a basic CLI system with speech for blind users who want CLI system? Using the Debian installer, there still is a lot of effort to be done to come up with a useful system. One shortcoming is an easy way to configure WiFi networks. Ceni is excellent but it's not in Debian repos, but in AntiX based on Debian or with smxi script. With smxi you can install browsers and editors easily. One bug that's a real pain is that somehow ldconfig doesn't get installed with the current CLI install. Arch Linux has a CLI install that's ready to go but it's not Debian which has it's advantages of it's own especially with stability. A CLI accessible installation CD would be a real asset. An easy console wifi setup would also help. Ceni works but it's difficult to understand with screen reader because it uses curses graphics. I'm assuming that by the CLI you mean 'console mode'. Debian is fully accessible using the CLI during and after installation. The option "install with speatch" is to be selected at install time, when installed exporting the en 'DEBIAN_FRONTEND=readline' will help using the CLI. >From what you are describing, it souns like the user needs to learn the CLI rather then the CLI not being accessible with 'espeakup'. -- John Doe
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
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
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
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
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 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: 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
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
espeakup fails to install
Debian buster. I have had an ongoing issue with espeakup loosing speech. I removed the package with a view to reinstalling but Reading package lists... Building dependency tree... Reading state information... The following NEW packages will be installed: espeakup 0 upgraded, 1 newly installed, 0 to remove and 49 not upgraded. Need to get 0 B/37.8 kB of archives. After this operation, 79.9 kB of additional disk space will be used. Selecting previously unselected package espeakup. (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55% (Reading database ... 60% (Reading database ... 65% (Reading database ... 70% (Reading database ... 75% (Reading database ... 80% (Reading database ... 85% (Reading database ... 90% (Reading database ... 95% (Reading database ... 100% (Reading database ... 166448 files and directories currently installed.) Preparing to unpack .../espeakup_1%3a0.80-10_i386.deb ... Unpacking espeakup (1:0.80-10) ... Setting up espeakup (1:0.80-10) ... Created symlink /etc/systemd/system/sound.target.wants/espeakup.service → /lib/systemd/system/espeakup.service. update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults Job for espeakup.service failed because the control process exited with error code. See "systemctl status espeakup.service" and "journalctl -xe" for details. invoke-rc.d: initscript espeakup, action "start" failed. ● espeakup.service - Software speech output for Speakup Loaded: loaded (#]8;;file://debian/lib/systemd/system/espeakup.service#/lib/systemd/system/espeakup.service#]8;;#; enabled; vendor preset: enabled) Active: activating (auto-restart) (Result: exit-code) since Sun 2018-10-14 16:36:24 BST; 39ms ago Docs: #]8;;man:espeakup(8)#man:espeakup(8)#]8;;# Process: 5156 ExecStart=/usr/bin/espeakup -V ${VOICE} #[0;1;31m(code=exited, status=2)#[0m Oct 14 16:36:24 debian systemd[1]: #[0;1;31m#[0;1;39m#[0;1;31mFailed to start Software speech output for Speakup.#[0m dpkg: error processing package espeakup (--configure): installed espeakup package post-installation script subprocess returned error exit status 1 Processing triggers for systemd (239-10) ... Processing triggers for man-db (2.8.4-2+b1) ... Errors were encountered while processing: espeakup E: Sub-process /usr/bin/dpkg returned an error code (1)
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.
loss of speech in speakup when switching between console and gui
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
speakup crashes
Hello, Can anyone reproduce this:- Debian buster updated on 19th september. When switching from desktop to one of the consoles, speech is lost in the console if orca is speaking at the time of changing to a command line. To reproduce:- 1 Login to the desktop. 2 Log in to one or more consoles. 3 Switch to the desktop and get orca to speak. 4 While orca is still speaking, change to the console. Result, Speakup appears to crash. Note pulseaudio is not installed. Regards Keith
Re: buster net install image speakup not starting
On 09/08/18 22:46, Samuel Thibault wrote: Keith Barrett, le jeu. 09 août 2018 21:10:25 +0100, a ecrit: On 09/08/18 16:05, Samuel Thibault wrote: There is no such known issue, netinst images should have speakup included. Then it looks like there is an issue, is there any information I can provide to help locate the issue? It may be a while until I can get some one to read the screen. Then you'd need a braille display to get the needed information if it's a problem with your particular system, and not just a bogus image. Right, I have a braille display which I have not used for some time, I will see what I can do and thank you for the degugging information. FTR, details on debugging information is on the wiki https://wiki.debian.org/accessibility#Debian_installer_accessibility Where did you take the image exactly? I followed the link to the images including firmware from the debian firmware wiki page. I guess you ended up on http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/buster_di_alpha3+nonfree/amd64/iso-cd/firmware-buster-DI-alpha3-amd64-netinst.iso but it'd be better to be sure, otherwise chasing bug where it is not is just loss of time... Yes, just checked and that is the correct image. Did you boot with BIOS (one beep) or UEFI (two beeps)? No beeps heard, Ok, it was just to make sure whether you need to press enter (BIOS boot) or not (UEFI boot) Right, so has the method of enabelling accessibility changed in buster? Samuel
Re: buster net install image speakup not starting
On 09/08/18 16:05, Samuel Thibault wrote: Hello, Keith Barrett, le jeu. 09 août 2018 15:29:02 +0100, a ecrit: Is there a knows issue with the buster installation images where speakup does not start? I used the image Debian GNU/Linux buster-DI-alpha3 "Buster" - Official Snapshot amd64 NETINST 20180612-18:52 I pressed "s" but got no speech. There is no such known issue, netinst images should have speakup included. Then it looks like there is an issue, is there any information I can provide to help locate the issue? It may be a while until I can get some one to read the screen. Where did you take the image exactly? I followed the link to the images including firmware from the debian firmware wiki page. Did you boot with BIOS (one beep) or UEFI (two beeps)? No beeps heard, I will try the same image on another computer and report back. Samuel
buster net install image speakup not starting
Hello, Is there a knows issue with the buster installation images where speakup does not start? I used the image Debian GNU/Linux buster-DI-alpha3 "Buster" - Official Snapshot amd64 NETINST 20180612-18:52 I pressed "s" but got no speech. Thanks Keith
Re: Introduction and using Orca with Debian sound systems
On 18/03/18 07:15, john doe wrote: Hi James, I'm sending this e-mail through the list in the hope that this nasty bug will be fixed once and for all. On 3/17/2018 5:54 PM, James AUSTIN wrote: Hi John On 17 Mar 2018, at 14:30, john doewrote: If you don't start orca is speakup speaking? Yes, Speakup speaks under the text console (CTRL+ALT+F1 etc). Orca does not speak under the MATE desktop. It looks like it's the pulse audio bug back again. Yes that is my conclusion also. I thought that this particular bug had been squashed years ago Sadly, this bug is still relevent. Basically, if orca is speaking, speakup won't speak!!! :) The only way i have managed to achieve is by setting speechd.conf to use ALSA, but I do not want to have to reset speechd.conf each time I want to s between the two Screen Readers. Is there a better way? Not that I know of. The only way I know is to remove pulseaudio completely, then speakup and orca work as expected. In my case I set the audio output to libao in /etc/speech-dispatcher/speechd.conf and all works for me.
Re: getting SPEAKUP TO SPEAK AT THE CONSOLE
Hello, This will be the pulseaudio problem again. You can make it all work by removing pulseaudio and setting output to libao in /etc/speech-dispatcher/speechd.conf It seems that later versions of firefox will require pulse to provide sound but, for me, it is more important to have speech in the console. On 08/02/18 05:33, john doe wrote: On 2/8/2018 2:12 AM, Mike Reiser wrote: Hello all, I just did a fresh install of debian using the internet iso image. Speakup talked durring installation but when I press control alt+F1 or another function key to bring up a console, I get no speech. Just was wondering how to get speakup to start talking when I press control+alt+F1 to bring up a console and how to get back to gnome and Orca when I'm done?Thanks, Sadly, it is an annoying bug! :) I had reported the same issue a while back and the issue was already known! The only way to use command line is to use the terminal provided by the desktop manager (Gnome, Mate ...).
pulseaudio and accessibility
Hello, I am not sure how practical it would be but I wonder if it would be possible to not install pulseaudio and set libao as the default output for speech-dispatcher when accessibility is called in the installer? It seems it is still not possible to use speakup in the console and orca at the desktop when pulse is on the system. I find lots of people who go through the install process only to find that speech is not working correctly once they reboot in to the new system. Removing pulse and changing to libao for speech-dispatcher mostly solves the issues. Regards Keith Barrett
Re: speech-dispatcher and debian buster
I should have added that I am using libao and pulseaudio is not installed. On 13/11/17 15:32, Keith Barrett wrote: Not sure if this is known bug but:- debian buster am64 last updated 13 November 2017 accessibility enabeled by installer. I get speech in lightdm but after logging in, speech is immediately lost. If I killall speech-dispatcher in console, all works normally. Could it be a problem with the transition between lightdm and user session with regards to speech-dispatcher? Regards Keith Barrett
speech-dispatcher and debian buster
Not sure if this is known bug but:- debian buster am64 last updated 13 November 2017 accessibility enabeled by installer. I get speech in lightdm but after logging in, speech is immediately lost. If I killall speech-dispatcher in console, all works normally. Could it be a problem with the transition between lightdm and user session with regards to speech-dispatcher? Regards Keith Barrett
libreoffice-writer not starting after updating stretch
Hello, I have 2 systems with Debian stretch i386 since updating both systems, libreoffice writer is not starting. Can't find any reports of this elsewhere so I wonder if it is something to do with orca or some other part of the accessibility stack. I have tryed starting by pressing enter on a document also by opening libreoffice and selecting write a document. In both cases, nothing happens. I have deleted the libreoffice directory in /home/keith/.config but that has no affect. Also reinstalled writer but no luck. Anyone else noticed this? Thanks
Re: problem with rc3 installer
On 12/04/17 17:27, Samuel Thibault wrote: Hello, Keith Barrett, on mer. 12 avril 2017 16:44:41 +0100, wrote: I am loosing speech every time I attempt the install. I think it may be a crash after the installer has been running for a while. Uh. Does it also happen with previous RC releases? (you can grab them from http://cdimage.debian.org/cdimage/ ) Does it happen with Jessie? I have an update. The am64 installer works as expected. So it looks like the problem is just with the i386. I don't think it is a hardware problem with the old machine as it is running stretch which was updated from the Jessie and all I did was replace the hard drive to install a clean stretch which I was going to test the speakup patches. Samuel
Re: problem with rc3 installer
On 12/04/17 17:27, Samuel Thibault wrote: Hello, Keith Barrett, on mer. 12 avril 2017 16:44:41 +0100, wrote: I am loosing speech every time I attempt the install. I think it may be a crash after the installer has been running for a while. Uh. Does it also happen with previous RC releases? (you can grab them from http://cdimage.debian.org/cdimage/ ) Does it happen with Jessie? Samuel It happens with the previous rc releases but Jessie is ok. I have another machine here so I could try the am64 version if that would help? So far I have tryed the i386.
problem with rc3 installer
Hello, Not sure what is happening but using Debian GNU/Linux stretch-DI-rc3 "Stretch" - Official Snapshot i386 NETINST Binary-1 20170409-00:50 I am loosing speech every time I attempt the install. I think it may be a crash after the installer has been running for a while. I mainly loose speech at the option to scan a second cd but on one occasion it stopped at the partitioning stage but I was called away so it may be time related. I do not have any sighted help here until next week so I may have more info then but I cannot get anything to happen by switching to another console or by any keystrokes. I have to force a reboot. Regards Keith
Re: x server crashes
On 13/12/2016 17:06, Keith Barrett wrote: Debian Stretch with mate desktop. After updating system on 12th November, xserver is crashing. Silly me, that should have been 12th December. I use startx to start the gui. Error in /usr/lib/xorg/Xorg': free(): Invalid Pointer: 0xb73107e0 backtrace: /lib/i386-linux-gnu/lib/c.so.6(+0x6dfb7)(0XB71cafb7) Connection to xserver lost. Is this a known issue? Keith Barrett
x server crashes
Debian Stretch with mate desktop. After updating system on 12th November, xserver is crashing. I use startx to start the gui. Error in /usr/lib/xorg/Xorg': free(): Invalid Pointer: 0xb73107e0 backtrace: /lib/i386-linux-gnu/lib/c.so.6(+0x6dfb7)(0XB71cafb7) Connection to xserver lost. Is this a known issue? Keith Barrett
Re: audio levels lost on reboot
On 19/10/16 12:48, Keith Barrett wrote: Is this a known issue? Debian jessie up to date as of 19/10/16. Sorry, senior moment, I meant to say stretch.. Setting levels with alsamixer or amixer and after rebooting, levels are back at previous low level. This is regardless of whether a gui is loaded as I boot to a console and run startx to load the gui. Keith Barrett
problem starting orca screenreader
Hope this is the right place for this. Debian testing, up to date at 17th October 2016. Using mate desktop and lightdm. Orca screenreader fails to start. If I boot to a command line and run startx all works as expected. One further issue is that audio levels are not saved so following every boot, I need to increase the audio levels. I have used alsamixer to set levels and also the sound tabb in the mate desktop but they are lost on reboot. Regards Keith Barrett