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.
