Speakup and non-ascii characters
Hello, This is in response to an email by Hermann, I am not doing it as a reply as I get messages as a digest and lost the original message.
First thing to note is that speakup as far as I know has its own character table which it uses for pronouncing characters when saying individual characters (eg. spelling, cursoring over characters, etc). This table can be found in /sys/modules/speakup/parameters/characters and so can be edited there. Speakup by default lists characters up to value 255, although values beyond 127 depend on the encoding used (eg. latin1, utf-8, etc) for the actual definition. As far as I know espeakup doesn't modify this table, speechd-up can replace the tables or leave them alone (there is an option for speechd-up to specify this).
One way to fix this is to create a script to modify the table or copy a new table into /sys/modules/speakup/parameters/characters and to do this on start up.
Does this help?
Michael Whapples
On 23.05.2009 at 23:01:54 Michael Whapples mwhapples@aim.com wrote:
Hello, This is in response to an email by Hermann, I am not doing it as a reply as I get messages as a digest and lost the original message.
First thing to note is that speakup as far as I know has its own character table which it uses for pronouncing characters when saying individual characters (eg. spelling, cursoring over characters, etc). This table can be found in /sys/modules/speakup/parameters/characters and so can be edited there.
Did you test this on a GRML machine? This path does not exist. Remember that Speakup is set up in a different way on GRML: Start with swspeak instead of adding a specific Speakup module to /etc/modules.
Speakup by default lists characters up to value 255, although values beyond 127 depend on the encoding used (eg. latin1, utf-8, etc) for the actual definition.
GRML is based on unicode and so should Speakup. Perhaps this is the problem?
As far as I know espeakup doesn't modify this table, speechd-up can replace the tables or leave them alone (there is an option for speechd-up to specify this).
Speechd-up relies on the settings of Speech-dispatcher, so it works in most cases, except the ones I discribed.
One way to fix this is to create a script to modify the table or copy a new table into /sys/modules/speakup/parameters/characters and to do this on start up.
How could such a script look like? I'm not a scripter, and how can this be implemented into the startup procedure?
Does this help?
Sorry, not really at the moment. Hermann
Firstly, sorry I made some simple mistakes which probably confused you, the main ideas are correct though. I think you hit the nail on the head when you mentioned that GRML uses unicode, I don't think the speakup character table is, hence the two are using different encodings, for example on my system when I type £ speakup will say it is an "u acute".
I gave the path /sys/modules/speakup/parameters/characters for the speakup character table, this should be /sys/module/speakup/parameters/characters (checked on my GRML HD installation and the GRML 2009.05RC1 CD, I believe also correct for the 2008.11 release, earlier ones I think may differ). Although you may start speakup differently on GRML it still is installed as modules, there's just some scripts to take certain boot options like swspeak and then load the correct modules and set some other things (eg. raise audio volume to something sensible).
Anyway hopefully you will now have the speakup table, and can read its structure (numerical value of character in first column, text which should make the synth say the correct character name in the second column).
I believe it is best to not modify the original table, so to edit it first thing is to copy it:
$ cp /sys/module/speakup/parameters/characters ~/speakup_characters.customised
Now edit the copy (in my above example ~/speakup_characters.customised). Once your happy with your modified version copy it back to the actual speakup table file (be certain it is what you want as once copied back speakup will use it).
$ cp ~/speakup_characters.customised /sys/module/speakup/parameters/characters
Now you may wish to store your customised version of the speakup table somewhere it may be perminantly stored (eg. USB drive).
Now on a HD installation you can add the copy command to a script and have it run at start up. Simplest may be to add the command to /etc/rc.local
Now for my comment regarding speechd-up. I was thinking of speechd-up version 0.4 but GRML uses speechd-up 0.3. In speechd-up 0.4 I think there is an option -t to tell speechd-up not to overwrite the speakup tables, I am not quite sure what speechd-up 0.3 does. However looking at the help message for speechd-up on the GRML 2009.05RC1 CD there is an option -c or --coding to specify the coding used, may be this has something to do with the table it overwrites the standard speakup character table. One word of warning, if you may switch to another synth while using speakup, speechd-up will not restore the speakup table when it exits, and so some hardware synths may not work as you would hope, either copy a new table to /sys/module/speakup/parameters/characters or restart the machine.
I hope now I have corrected some of those mistakes things are clearer.
Michael Whapples On -10/01/37 20:59, Hermann wrote:
On 23.05.2009 at 23:01:54 Michael Whapplesmwhapples@aim.com wrote:
Hello, This is in response to an email by Hermann, I am not doing it as a reply as I get messages as a digest and lost the original message.
First thing to note is that speakup as far as I know has its own character table which it uses for pronouncing characters when saying individual characters (eg. spelling, cursoring over characters, etc). This table can be found in /sys/modules/speakup/parameters/characters and so can be edited there.
Did you test this on a GRML machine? This path does not exist. Remember that Speakup is set up in a different way on GRML: Start with swspeak instead of adding a specific Speakup module to /etc/modules.
Speakup by default lists characters up to value 255, although values beyond 127 depend on the encoding used (eg. latin1, utf-8, etc) for the actual definition.
GRML is based on unicode and so should Speakup. Perhaps this is the problem?
As far as I know espeakup doesn't modify this table, speechd-up can replace the tables or leave them alone (there is an option for speechd-up to specify this).
Speechd-up relies on the settings of Speech-dispatcher, so it works in most cases, except the ones I discribed.
One way to fix this is to create a script to modify the table or copy a new table into /sys/modules/speakup/parameters/characters and to do this on start up.
How could such a script look like? I'm not a scripter, and how can this be implemented into the startup procedure?
Does this help?
Sorry, not really at the moment. Hermann
On 24.05.2009 at 17:32:08 Michael Whapples mwhapples@aim.com wrote:
Firstly, sorry I made some simple mistakes which probably confused you, the main ideas are correct though. I think you hit the nail on the head when you mentioned that GRML uses unicode, I don't think the speakup character table is, hence the two are using different encodings, for example on my system when I type £ speakup will say it is an "u acute".
Speakup uses Unicode and this causes the problem: I figured that out when starting speechd-up with: speechd-up -c UTF-8 I get the same char mixup than in Espeakup. When using ISO-8859-15, which seems to be the standard for Speechd-up, it works almost right, with the described exceptions.
I gave the path /sys/modules/speakup/parameters/characters for the speakup character table, this should be /sys/module/speakup/parameters/characters (checked on my GRML HD installation and the GRML 2009.05RC1 CD, I believe also correct for the 2008.11 release, earlier ones I think may differ). Although you may start speakup differently on GRML it still is installed as modules, there's just some scripts to take certain boot options like swspeak and then load the correct modules and set some other things (eg. raise audio volume to something sensible).
Right, and my fault was that I deactivated "swspeak", so no modules were loaded and no directories are there.
Anyway hopefully you will now have the speakup table, and can read its structure (numerical value of character in first column, text which should make the synth say the correct character name in the second column).
I believe it is best to not modify the original table, so to edit it first thing is to copy it:
$ cp /sys/module/speakup/parameters/characters ~/speakup_characters.customised
Now edit the copy (in my above example ~/speakup_characters.customised). Once your happy with your modified version copy it back to the actual speakup table file (be certain it is what you want as once copied back speakup will use it).
$ cp ~/speakup_characters.customised /sys/module/speakup/parameters/characters
I followed your instructions and I had to learn that it is not possible to copy the edited file back, because the operation is not allowed. I figured this out when I tried to remove the original file, because copying gave no error messages, but the old file persists. The directory is in use and can not be changed. Unloading the Speakup modules results in disappearance of the directory. So, either I don't understand the whole procedure, or something is terribly screwed up on GRML.
Now you may wish to store your customised version of the speakup table somewhere it may be perminantly stored (eg. USB drive).
Now on a HD installation you can add the copy command to a script and have it run at start up. Simplest may be to add the command to /etc/rc.local
Would not work, see above.
Now for my comment regarding speechd-up. I was thinking of speechd-up version 0.4 but GRML uses speechd-up 0.3. In speechd-up 0.4 I think there is an option -t to tell speechd-up not to overwrite the speakup tables, I am not quite sure what speechd-up 0.3 does. However looking at the help message for speechd-up on the GRML 2009.05RC1 CD there is an option -c or --coding to specify the coding used, may be this has something to do with the table it overwrites the standard speakup character table. One word of warning, if you may switch to another synth while using speakup, speechd-up will not restore the speakup table when it exits, and so some hardware synths may not work as you would hope, either copy a new table to /sys/module/speakup/parameters/characters or restart the machine.
I answered to this partially above, but to accomplish, I have to say that indeed GRML uses 0.3, and on a former installation I had 0.4, which worked right. Cannot remember that -t option, but it was not necessary, since 0.4 seems to use SD's settings.
I hope now I have corrected some of those mistakes things are clearer.
Thank you for your patience, but there still is some troubble. Hermann
I tried some stuff on my system. Here is what I found.
When I edited the copy of the table I used nano for my editor and it added an extra blank line and so when I tried to copy the table into /sys/module/speakup/parameters/characters it didn't go in because of the extra line. You should have a single new line character following the last entry in the table (nano made it two new lines). However I didn't get any error message with this copying, it just didn't go in. When I corrected the table and then tried to copy it, everything worked fine.
I am trying this on a hard disk installation of GRML, I will have a go with a CD in a minute.
Michael Whapples On 25/05/09 12:58, Hermann wrote:
On 24.05.2009 at 17:32:08 Michael Whapplesmwhapples@aim.com wrote:
Firstly, sorry I made some simple mistakes which probably confused you, the main ideas are correct though. I think you hit the nail on the head when you mentioned that GRML uses unicode, I don't think the speakup character table is, hence the two are using different encodings, for example on my system when I type £ speakup will say it is an "u acute".
Speakup uses Unicode and this causes the problem: I figured that out when starting speechd-up with: speechd-up -c UTF-8 I get the same char mixup than in Espeakup. When using ISO-8859-15, which seems to be the standard for Speechd-up, it works almost right, with the described exceptions.
I gave the path /sys/modules/speakup/parameters/characters for the speakup character table, this should be /sys/module/speakup/parameters/characters (checked on my GRML HD installation and the GRML 2009.05RC1 CD, I believe also correct for the 2008.11 release, earlier ones I think may differ). Although you may start speakup differently on GRML it still is installed as modules, there's just some scripts to take certain boot options like swspeak and then load the correct modules and set some other things (eg. raise audio volume to something sensible).
Right, and my fault was that I deactivated "swspeak", so no modules were loaded and no directories are there.
Anyway hopefully you will now have the speakup table, and can read its structure (numerical value of character in first column, text which should make the synth say the correct character name in the second column).
I believe it is best to not modify the original table, so to edit it first thing is to copy it:
$ cp /sys/module/speakup/parameters/characters ~/speakup_characters.customised
Now edit the copy (in my above example ~/speakup_characters.customised). Once your happy with your modified version copy it back to the actual speakup table file (be certain it is what you want as once copied back speakup will use it).
$ cp ~/speakup_characters.customised /sys/module/speakup/parameters/characters
I followed your instructions and I had to learn that it is not possible to copy the edited file back, because the operation is not allowed. I figured this out when I tried to remove the original file, because copying gave no error messages, but the old file persists. The directory is in use and can not be changed. Unloading the Speakup modules results in disappearance of the directory. So, either I don't understand the whole procedure, or something is terribly screwed up on GRML.
Now you may wish to store your customised version of the speakup table somewhere it may be perminantly stored (eg. USB drive).
Now on a HD installation you can add the copy command to a script and have it run at start up. Simplest may be to add the command to /etc/rc.local
Would not work, see above.
Now for my comment regarding speechd-up. I was thinking of speechd-up version 0.4 but GRML uses speechd-up 0.3. In speechd-up 0.4 I think there is an option -t to tell speechd-up not to overwrite the speakup tables, I am not quite sure what speechd-up 0.3 does. However looking at the help message for speechd-up on the GRML 2009.05RC1 CD there is an option -c or --coding to specify the coding used, may be this has something to do with the table it overwrites the standard speakup character table. One word of warning, if you may switch to another synth while using speakup, speechd-up will not restore the speakup table when it exits, and so some hardware synths may not work as you would hope, either copy a new table to /sys/module/speakup/parameters/characters or restart the machine.
I answered to this partially above, but to accomplish, I have to say that indeed GRML uses 0.3, and on a former installation I had 0.4, which worked right. Cannot remember that -t option, but it was not necessary, since 0.4 seems to use SD's settings.
I hope now I have corrected some of those mistakes things are clearer.
Thank you for your patience, but there still is some troubble. Hermann
On 25.05.2009 at 14:34:45 Michael Whapples mwhapples@aim.com wrote:
I tried some stuff on my system. Here is what I found.
When I edited the copy of the table I used nano for my editor and it added an extra blank line and so when I tried to copy the table into /sys/module/speakup/parameters/characters it didn't go in because of the extra line. You should have a single new line character following the last entry in the table (nano made it two new lines). However I didn't get any error message with this copying, it just didn't go in. When I corrected the table and then tried to copy it, everything worked fine.
OK, that was it. Reediting the file with emacs did the trick. Note: You can change the config file of nano, so that this additional line isn't put in. I'll do so. One question about /etc/rc.local: Where to put the cp command? Before or after that "exit 0" line? Hermann
Your question about where to put the copy command, better be before the exit 0 line as the exit command does what it says and will exit the script at that point. Sometimes those exit commands are put in start up scripts so you can disable them (IE. the exit command will be near the beginning so that either you comment it out to enable the script or uncomment it to disable the script).
Michael Whapples On 25/05/09 13:53, Hermann wrote:
On 25.05.2009 at 14:34:45 Michael Whapplesmwhapples@aim.com wrote:
I tried some stuff on my system. Here is what I found.
When I edited the copy of the table I used nano for my editor and it added an extra blank line and so when I tried to copy the table into /sys/module/speakup/parameters/characters it didn't go in because of the extra line. You should have a single new line character following the last entry in the table (nano made it two new lines). However I didn't get any error message with this copying, it just didn't go in. When I corrected the table and then tried to copy it, everything worked fine.
OK, that was it. Reediting the file with emacs did the trick. Note: You can change the config file of nano, so that this additional line isn't put in. I'll do so. One question about /etc/rc.local: Where to put the cp command? Before or after that "exit 0" line? Hermann
On 25.05.2009 at 14:34:45 Michael Whapples mwhapples@aim.com wrote: [...] The next problem has arrived: Speakup now spells the chars right, but doesn't read them in their context, e. g. words with umlauts are not spoken correctly, the umlauts were ommited. So the question is: Based on which Espeak was Espeakup compiled? I remember that old versions of Espeak couldn't read unicode chars correctly, if they were beyond ASCII 127. One had to start Espeak with an Option, I think it was -b. Speechd-up now works perfectly. But: Due to an unsolved issue with libasound2, SD sometimes crashes; it hasn't been fixed till now. The SD team knows about that, but they couldn't figure out what's going on, since this happens not on all machines. Hermann
Hello, Seems like you may be correct about the -b option, when I do:
$ espeak --help
it mentions the -b option being for 8-bit encoding. Unfortunately I don't know how to get espeakup to set this up as the man page for espeakup doesn't list any options related to that. I think this may be a problem with espeakup rather than GRML's espeakup package. I am sorry I can't suggest much more than may be try and get espeakup from git and compile it, or try asking on the speakup list (I know the author of espeakup views the speakup list).
Michael Whapples On 25/05/09 14:45, Hermann wrote:
On 25.05.2009 at 14:34:45 Michael Whapplesmwhapples@aim.com wrote: [...] The next problem has arrived: Speakup now spells the chars right, but doesn't read them in their context, e. g. words with umlauts are not spoken correctly, the umlauts were ommited. So the question is: Based on which Espeak was Espeakup compiled? I remember that old versions of Espeak couldn't read unicode chars correctly, if they were beyond ASCII 127. One had to start Espeak with an Option, I think it was -b. Speechd-up now works perfectly. But: Due to an unsolved issue with libasound2, SD sometimes crashes; it hasn't been fixed till now. The SD team knows about that, but they couldn't figure out what's going on, since this happens not on all machines. Hermann
Teilnehmer (2)
-
Hermann -
Michael Whapples