Sound Card selection at boot

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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.

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

 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

[Keith Barrett]

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

[Keith Barrett]

On 04/11/18 18:36, Samuel Thibault wrote:

Keith Barrett, le dim. 04 nov. 2018 18:32:41 +, a ecrit:

On 04/11/18 13:48, Didier Spaier wrote:

On 04/11/2018 14:37, Keith Barrett wrote:



On 03/11/18 19:54, Didier Spaier wrote:

Hello,

I should have stated that this binary is a 64-bit one.

Maybe you have a 32-bit system?

No, I have a 64-bit system.
Just thinking about it later, could it be a permissions/ownership issue?

i
Just in case, try again, this time typing as root after having copied the file:
chown root:root /usr/bin/espeakup
chmod 755 /usr/bin/espeakup.


Success, it must have been permissions.
I have been switching between X and the console and so far, after a few
hours, no crashes at all.

Thank you Didier for your efforts, a long standing issue solved for me, can
we get the change included in debian?


Not that simply since as I mentioned the setup that Didier uses is not
the default setup configured by the pulseaudio package. That needs to be
discussed with pulseaudio maintainers.
I thought that this was a different issue as I do not have pulseaudio on 
this system and I still had the problem before Didier's modification and 
now the problem is corrected.





Samuel

Re: loss of speech in speakup when switching between console and gui

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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 doe  wrote:

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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

[Keith Barrett]

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