Hi Kirk OK, I've been playing with this some more. I believe the fault is in part with speechd-ups priorities and partly the softsynth driver. Here's the situation as I see it: The softsynth driver itself, for whatever reason, will not interrupt the speech, you were right about that. What did allow speech to be interrupted was the text priority that speechd-up uses. Text is a self-interrupting priority and, while the softsynth driver may not know how to shut speech off, speechd does. This would explain why enter doesn't work, but another screen review key does, the single shut-up command never reaches speechd-up, but new text does and triggers the appropriate action. Reading the whole screen is a different matter, however. Since text is self-interrupting, while reading the screen, it will interrupt itself. As of yet, I'm not really sure precisely what happens, but if you send text after text after text to speechd, the new text will continually interrupt the old, creating the effect. This can be fixed by altering speechd-up slightly, which I've done, but not contributed to the project maintainer as of yet. The reason I've not sent it to the maintainer is that it comes with a tradeoff, that being speech interruptability is severely reduced. New text won't interrupt the old under *any* circumstance, meaning that if you push a key that changes the screen, it will not speak the changed screen until it finishes what it was speaking before. The only way to interrupt it is to use a screen review key, this is because I altered speechd-up to give screen review keys the self-interrupting text priority, while giving screen output the message priority, which is not self-interrupting. In fact, if the bug in the softsynth driver could be squashed, I think speakup might have a quite useable software synth option. Speechd does know how to interrupt the speech, so if the softsynth driver could just send the shut-up command through, I think it would probably produce the intended results. Regards On Sun, 28 Mar 2004, Kirk Reiser wrote: > Well, although what you are saying makes some sense I don't think it > really applies here. For one thing shutting up a single line of text > is quite easy because the processing of that line it finished way > before the line is done speaking but the next up arrow or whatever > gets acted on immediately because it is seen quite quickly because the > processing is basically finished. If you do a say screen there are no > other priorities to get in the way or override because that is the > only operation being output at the time. So it should speak to > completion in that case because there isn't anything else but it > won't. It'll stop after just a few lines everytime.
