Dectalk Linux Question

[Jacob Schmude]

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.