Hi Jacob: Sorry for the delay in responding to this message. I wanted to look over the code before responding and didn't have time until this morning. I'll comment on your quoted points below. > 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. This is actually a bug in speechd-up in that case. It should specifically be looking for characters it is suppose to take action on like flush, synth commands and speech processing characters such as carrage return if that's what they want to use. They should have implemented the time out command which is sent on opening the device to process speech after a certain amount of time has passed with no other processing characters. >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. This of course is a cosmetic change which is fine. I will change the line in the cvs version of the softsynth code to reflect your suggestion. It won't have any affect on code operation though. > 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. This is the clincher that it is a speechd-up bug. I will take a look at the speechd-up module to see if I can make some changes which will cause it to behave correctly. The process speech translation character should actually be done in the individual synth drivers on the speech dispatcher output side because each synth will have it's own idea what should be used for indicating when the incoming text should be processed. Some synths use a carrage return, some use a newline character, others use nulls and synths like Dectalks use multiple characters such as commas, periods and other phrase ending indicators. It sounds however like they are not opening the device so that the characters are received as they come into the softsynth device. Kirk -- Kirk Reiser The Computer Braille Facility e-mail: kirk at braille.uwo.ca University of Western Ontario phone: (519) 661-3061
