Dectalk Linux Question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Jacob,
  I am curious to know when these changes will be made to the Speechdup project on the web? I'd love to use Speakup with the software Dectalk and have full access to the Bash shell with it.
Regards
Steve


*********** REPLY SEPARATOR  ***********

On 4/3/2004 at 8:27 PM Jacob Schmude wrote:

>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.
>
>_______________________________________________
>Speakup mailing list
>Speakup at braille.uwo.ca
>http://speech.braille.uwo.ca/mailman/listinfo/speakup


Stephen Clower, that guy from the south.
You can reach me by any of the following:
E-Mail: steve at steve-audio.net
MSN: steve at steve-audio.net
AIM: AudioRabbit03

You can also check out my little home on the web by visiting http://www.steve-audio.net
    





[Index of Archives]     [Linux for the Blind]     [Fedora Discussioin]     [Linux Kernel]     [Yosemite News]     [Big List of Linux Books]
  Powered by Linux