Dectalk Linux Question

Kirk Reiser kirk at braille.uwo.ca
Thu Apr 8 10:19:46 EDT 2004


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




More information about the Speakup mailing list