Dectalk Linux Question

[Jacob Schmude]

Hi
Actually, I'm not sure the buffer is at fault. The way it was explained,
on the speechd list at least, was that speechd has different priorities of
text. How it determines these priorities I don't know, butif it encounters
a higher priority item, it will stop reading what it was reading and
immediately read the new item. A good example is within lynx the chain, if
there's no URL at the bottom of the screen then the entire screen will
read. If there is, immediately for some reason the last part of the URL is
spoken and the rest of the screen is not read. This is also why command
not found errors aren't read, the shell prompt has a higher priority so it
gets read instead. I think what would have to be done would be to have
speechd_up ignore priorities completely, as they really aren't needed when
using a screen reader and can in fact be a nuisance. If I had to guess.
this is also part of the shut up problem, as a shut up key with no text
gets ignored as a very low priority item. Remember, its not that speech
won't interrupt, just that it won't interrupt if you don't send any text
with it. If you read a line then move up to the previous line, then it
will interrupt quite quickly and begin reading that line.

On Sun, 28 Mar 2004, Kirk Reiser wrote:

> This was an excellent overview Jacob,  I think you should forward it
> on to the speech dispatcher list as well.  A lot of the things you
> mentioned can be fixed with further fixes to their speakup driver
> converting the pitch and voices and the like into the appropriate
> commands for the software dectalk and/or other synths they support.
>
> I found two problems but haven't had time to try to  look into them
> which were that if you have to large of buffer say with a say screen
> you lost everything after 256 or 512 bytes.  The other problem was
> what seems to me to be the software synth nemisis it won't shut up
> when you hit the key what says shut up!