GNOME Bugzilla – Bug 526753
Certain strings crash Orca if viavoice/ibmtts/voxin is used
Last modified: 2008-06-03 19:38:54 UTC
From Halim on the Orca list: ----------------------------- Gnomespeech crashs if ibmtts gets some words. The german viavoice crashes if it gets dage-gen or dane-ben ... If this happens orca crashes as well. When I switch to orcas speechd backend the ibmtts module of speechd crashs but not orca. So I am able to restart the services using my braille display. ----------------------------- This is one of those "blast from the past bugs". A few years ago, Eloquence users discovered that the following string would crash (or hang, I forget which now) their Windows screenreader: 'c a e s u r e' -- spaced/spelled out to prevent Orca from crashing. Which brings me to: If you enable word echo and type that string as a word with Voxin as your synth using gnome-speech, Orca will crash. :-( I'll send a note off to the Voxin guys because this shouldn't be happening. In the meantime, are there any defensive measures we (or gnome-speech) can take so that Orca doesn't crash when these strings are encountered?
We could potentially add a 'sounds like' pronunciation to the pronunciation dictionary. As a potential test (and workaround), we could ask the user to customize their own pronunciation dictionary.
(In reply to comment #1) > We could potentially add a 'sounds like' pronunciation to the pronunciation > dictionary. As a potential test (and workaround), we could ask the user to > customize their own pronunciation dictionary. > Perhaps have a temporary user-customizations.py file made? Or something in the part of orca that handles the speaking of strings.
Will, that works for the offending string for the English synth. I assume it will work for the German ones as well....
(In reply to comment #3) > Will, that works for the offending string for the English synth. I assume it > will work for the German ones as well.... OK. Let's see what Halim has to say. If it works, I think we can downgrade this to minor since an easy workaround is available.
Oh shoot. That won't work. It works in terms of not crashing when you come across that word in normal uses (like in a document), but if you arrow around in your pronunciation dictionary and land on that word we still crash: We are intentionally not using the altered pronunciation for the actual string in that tree so that the user can use speech to identify what's in that column.
(In reply to comment #5) > Oh shoot. That won't work. It works in terms of not crashing when you come > across that word in normal uses (like in a document), but if you arrow around > in your pronunciation dictionary and land on that word we still crash: We are > intentionally not using the altered pronunciation for the actual string in that > tree so that the user can use speech to identify what's in that column. > Is there no way of creating a blacklist of words / phrases? So that the engine that speaks strings could search this list, and if the current work was found, it could just say "Disallowed word" or something. HTH.
Well...darn. Editing the orca-customizations.py file by hand is likely to cause the same crash. So, this would need to live lower in the stack. The obvious place, of course, is the speech synthesis engine itself. ;-) Given the lifespan of viavoice/ibmtts on Linux (i.e., it currently requires old libraries), I'm not sure how much time we should spend working around a problem in a product whose days are currently numbered. I'm really not thrilled at the thought of a workaround in gnome-speech because I suspect this might be one of those never-ending rat holes where we continually play the "find yet another word to crash the synth" game, and each new set of words found would require a new release of gnome-speech.
> Is there no way of creating a blacklist of words / phrases? So that the engine > that speaks strings could search this list, and if the current work was found, > it could just say "Disallowed word" or something. There currently is no such thing. It's also a Catch-22 situation. To define the blacklist, you need to type the actual string. If you type the actual string, you will probably end up sending it to the synth.
(In reply to comment #7) > Well...darn. Editing the orca-customizations.py file by hand is likely to > cause the same crash. Not if you're very, very careful. ;-) Turn off word echo, don't arrow to that line, but just type the string, save the file, and then close it very gingerly. ;-) The problem is that you can never ever arrow around in your pronunciation dictionary (i.e. in the Preferences dialog) again. :-( I emailed the oralux support address. When I bought Voxin a while back and then didn't get around to actually downloading it, Giles followed up promptly to be sure I had all the info I needed. I'm hoping for a similarly prompt response regarding this issue. <fingers crossed>
(In reply to comment #8) > > Is there no way of creating a blacklist of words / phrases? So that the engine > > that speaks strings could search this list, and if the current work was found, > > it could just say "Disallowed word" or something. > > There currently is no such thing. It's also a Catch-22 situation. To define > the blacklist, you need to type the actual string. If you type the actual > string, you will probably end up sending it to the synth. > Not if the blacklist is just a straight text file. All you'd have to do is type the word and press enter, reload orca, then reading the textfile would just say a lot of "Disallowed word" or whatever the chosen phrase was, unless the user read character by character.
> Not if the blacklist is just a straight text file. All you'd have to do is type > the word and press enter, reload orca, then reading the textfile would just say > a lot of "Disallowed word" or whatever the chosen phrase was, unless the user > read character by character. As Joanie mentions - you'd have to do this very carefully. No word echo, no line review, nothing, when you're entering the data.
> As Joanie mentions - you'd have to do this very carefully. No word echo, no > line review, nothing, when you're entering the data. > If there was a comment placed at the top of the file: # This is the black list for all the strings you don't want to be spoken at all, that bypasses even # the pronounciation dictionary. # # You might want to silence your speech after this point. # Do this by pressing ORCA + s. <ListOfWords> I don't want to keep going on about it, but this is the standard way of stopping things from happening, from odprobe upwards- I just think it's a good idea. HTH.
Created attachment 108807 [details] [review] could we do something like this....? Halim responded to me (and on the list, I believe): -------------- The more important one is that orca should not crash if a speech output synthesizer crashes. This works currently well in speech-dispatcher. When the synth crashes orca works only with braille. That should be the behaviour in gnome-speech too. -------------- I didn't take a very thorough look at this problem so consider the attached a proof of concept rather than as a solution. But if all we want to do is terminate speech and let braille continue, couldn't we??
This just in from Gilles: -------------------------- Joanmarie Diggs wrote: > Is there anything that can be done on > your end to fix this problem? > If there is no fix from IBM, the known fatal words could be probably automatically modified. Personnaly, I could focus on this after mid June. Best regards, Gilles
(In reply to comment #13) > Created an attachment (id=108807) [edit] > could we do something like this....? In the code in question, Orca has detected that the speech synthesis engine has crashed very quickly a couple times in a row. As a result, Orca is aborting on purpose because it doesn't really know what to do. That is, technically, Orca is not crashing. Rather run down what might end up being an endless rat hole of discussion for a problem with no good solution except to fix it at the source, I think the way forward on this would be to go down the black list route, allowing users to add words to the "black list" in some way. I put "black list" in quotes because this really would be a hidden pronunciation dictionary that provides substitute "sounds like" pronunciations for words. If you wanted to really black list something, you could just make an empty entry in the dictionary. This would only catch words and not phrases (i.e., it would catch "flaky_tts_engine" but not "flaky tts engine"), but I think that is fine. For quick thoughts on how I might do it if I wanted to make other higher priority tasks suffer while I worked on this problem, I might put a 'hidden' pronunciation dictionary in pronunciation_dict.py and augment pronunciation_dict.py:getPronunciation to draw first from pronunciation_dict.py:pronunciation_dict and then from the hidden dictionary (making sure to override anything given from pronunciation_dict). 'hidden' in this case means a Python public dictionary that other modules can see, but it is hidden from editing by the preferences GUI. I would also make the hidden dictionary empty by default and require users to add words to it via their ~/.orca/orca-customizations.py and/or ~/.orca/user-settings.py files. Another way might be to make a non-GUI-editable dictionary that parallels the pronunciation_dict, and use it right after the call to orca_state.activeScript.adjustForPronunciation in gnomespeechfactory.py.
At team meeting today we agreed to not adopt the blacklist approach. I will ping Gilles because it would be nice to not have this issue.