Dectalk Linux Question

[Jacob Schmude]

Hi Kirk
   Well, I think I have it. Basically, what happens with speechd-up is
that it won't process anything, and I do mean anything, until it gets a
carriage return. This includes flush commands, so I altered the driver to
take this into account. What I did:
	1. On line 32, you have:
#define CLEAR_SYNTH 0x18
I changed it to:
#define SYNTH_CLEAR 0x18
I don't know if this helps or not, but it keeps consistancy with the other
drivers that use this particular preprocessor definition.
	2. In the softsynth_flush function, I changed the line that reads:
synth_write( "\x18", 1 );
to read:
synth_write( "\x18\x0d", 2 );
	This passes a carriage return along with the flush command, which
causes speechd-up to see it. As a result, I don't need my checking feature
in speechd-up anymore, it sees it already. Now, it shuts up right when it
should and keeps speaking when it should, just like a hardware synth
does. This fixes any synth running through speechd-up, since they use the
same common interface. What will happen with something like tuxtalk, I'm
not sure, but it seems to work fine through speechd-up on my system.

Regards, and thanks for your help and tolerance.

On Sat, 3 Apr 2004, Kirk Reiser wrote:


> Hi Jacob:  The only time any driver sends out a flush is on a
> keystroke of some type.  The Dectalk family of synths are very
> difficult to communicate with because they expect the flush character
> to wait on them returning a character indicating that the clear has
> been accomplished.  This is very difficult to do when you are watching
> time by the millisecond so what we do instead is send the flush
> character wait a short period of time and if we haven't received the
> all clear responce go on anyway.  This happens because the Decs don't
> return the character until they've emptied the synths buffer which as
> you probably know with the Dectalks is very sluggish.  I will have to
> look at the dectalk driver again though because it has been some time
> since I wrote it and David Borowski rewrote it.
>
> Suffice to say that the mechanism which sends out characters for the
> softsynth is the same as for the other synths Dectalk included and
> they are all the same in that speakup handles them all from the same
> array of structures.  So there is still some confusion here or
> miscommunication we need to clear up.
>
> I am very happy to hear you are getting better results with your
> rewrites.  I recommend also if you haven't already that you take a
> look at the syftsynth driver because it is really a very very simple
> driver.  I'm sure it is the most simple of all our drivers because I
> didn't try to build in any techniques for dealing with the various
> idiosynchracies of the actual hardware synths.