[DECtalk] An Answer from Greg in the Speakup List

[Chime Hart]

I am so, sorry, I sent along Don's comments instead of Greg's. Here is Greg
Hi All: I think I remember in Vocal-Eyes, we could hit a control+n to send
  commands directly to a synthesizer. Does Speakup have such a way?

Yes, synth_direct. Using bash, as root:

echo "hello" /sys/accessibility/speakup/synth_direct

should make your dectalk say hello.

  Reason I
  ask, on the DecTalk discussion list, we've been discussing my long-standing
  Speakup related sudden changes in pitch, rate, and volume. And so this
  question came up about a bipass. To continue, here are Don's comments from
  earlier today
  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.

You could rmmod speakup_dectlk, and you should be able to send
whatever you want to the dectalk using echo to the serial port. Of
course, as soon as you modprobe speakup_dectlk, speakup would set the
dectalk parameters. So, your best option seems to be to communicate to
the dectalk through synth_direct.


  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.)

As far as speakup settings, those should be in speakup_dectlk.c in the
speakup source.


  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.

In order to set the parameters of the unit, speakup needs to send
various control characters to the unit, and does so.

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

This is again in the speakup source code. Speakup doesn't do anything
that isn't in its source code.

  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.

I'm not sure it's possible to view input/output of a line discipline
in use, which is how speakup communicates with the synthesizer.

  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.

Speakup is in the kernel, so no writing to log files. It should be
possible to write input/output between speakup and the synthesizer to a buffer in memory
which could be queried by a user space tool.

Greg