[DECtalk] An Answer from Greg in the Speakup List

[Chime Hart]

Hi All: Well, I received some good analysis of this Speakup/DecTalk issue. Greg 
quoted my original message, which I removed all those anoying greater than 
signs. Before we get to his comments, I tried his solution, but I guess this 
only works as real root, not sudo 
The problem is that we can't talk to the DECtalk without going through
SpeakUp.  To test the condition you pose, we could tell DECtalk to use
some other voice.  Then, after the "drop" happens, see if it has reset
the parameters of THAT voice... or, changed to the voice that SpeakUp
*thought* was being used.

We also don't know what the values are reverting to.  Or, what their
various defaults might be (power up, nonvolatile memory, speakup settings,
etc.)

For an original DECtalk, we could enable logging and just look at the
characters that were being sent to the DECtalk by SpeakUp.  If there
are no control sequences that try to alter these settings, then we
would KNOW that it was something that was happening inside the DECtalk
unit.

If, on the other hand, we see some commands being sent but they are
incorrect, then we know the problem lies in SpeakUp.

I don't know how to divorce the serial interface from SpeakUp so that
we can eavesdrop on it.  There are some ways to do this but I don't
know how they will color the results.

The better solution would be if SpeakUp had a debug mode that caused
all output to be copied to some log file that could be analyzed after
a "drop" was noticed.  You could then manually examine the log and
identify whether SpeakUp was causing a parameter change or not.

This would also help the developers backtrace to see why the commands
were being issued and why they weren't correct.
Chime