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

Re: [SpeechIO-12] speechd v0.39

> Kyle: you're still sending multiple messages :)

Ok, I'll try not to keep hitting the 'y' so inccessantly in pine...

> I had verified that while catspeech is maintaining an open connection to
> /dev/speech (and speechd is doing the same), other things can still write
> to /dev/speech and be spoken.  

Ok, then the FIFO provides that functionality.  Good.  

> I had been having a confusing problem, with speechd stopping speaking, but
> I was thinking that it was caused by the killing & restarting involved in
> development & would not occur for users.
> What you've said -- the EOF sent by programs (like echo test >
> /dev/speech) makes sense.  It's possible that my problems happened to
> coincide with such tests (echoing to /dev/speech).  So the next thing I
> intend to do is change the code to do...
> while (1)
> {
>   open FIFO, $fifo;
>   while ($text = <FIFO>)
>   {
>     (send text to festival)
>   }
>   close FIFO;
> }
> so that it can handle such occurrences.  Then it'll only close & reopen
> the fifo when a program which had been writing to /dev/speech closes it.

Isn't this one of the  original problems?  where we have to sleep to keep
from screwing up on the reopen on the FIFO?  Won't we have to do as perlipc
says?  This is less than optimum imo.

> And I think you were noting that if someone did a "echo test >
> /dev/speech", it could possibly cause dropped lines (by overrwriting
> current contents of /dev/speech).  So document this and tell them not to ?
> And incourage people to not close write connections to the /dev/speech
> file.  Yeah, it'll still close & re-open once in a while, but we should be
> able to keep it to a real minimum.  

That will work for us, but the idea (at least as I remember it) for /dev/speech
was for it to be as simple as possible.  To allow people to 'cat' stuff
to the device file and have it spoken.  That would be the best encouragement
for getting others to use our work -- the simpler our interface is, the
more widely used it will be.  Also, when we were talking about being able
to send control statements through the fifo to speechd, we could implement
that via an ioctl() call on /dev/speech if we use the kernel module approach.

> I don't know.. do you think that periodic closing & reopening is
> sufficient reason to deal w/ a kernel module ?  Especially ease of
> installation & compatibility issues ?

If they break and it's not our fault, then they'll code around it.  If we
break, and it's our fault, they'll drop our software like a hot potatoe.
If you're an end user, and periodicly something sends the eof to speechd,
causing it to fail in some way (either stop, or drop lines), are you going
to be happy?  What if it's not your software, are you (as an end user of our
software) going to write to the maintainer of that software (what if it's 
commericial?) and get them to chagne it?  

> Hmm... instead of
> while ($text = <FIFO>
> {
>   (write $text to festival)
> }
> Could we do 
> while (1)
> {
>   $text = <FIFO>;
>   (write $text to festival)
> }
> Would that fix the problem ?
> I feel like we tried that once & it didn't work.  Hmm.
> Oh... right... the EOF would kill it & it'd never reopen.  Right ?


> That would be ideal.  I just don't know if...  
> it'd be more difficult to impliment, maintain, and install.  Is it worth
> it ?
> Geez... just one characger... a ^D....
> You'd think we could ignore it.

unfortunatly the libc implementation of stdio (which is used by perl) doens't
grab that as a characer, it's an event, not data.

as far as it being worth it, isnt it?  how hard is it really?  the first
version of the kernel module is done.  Has anyone tried it out yet to see if
it fixes our problems?


"Perl combines all of the worst aspects of BASIC, C and line noise." 
    -- Keith Packard <keithp@ncd.com>
mortis@voicenet.com                            http://www.voicenet.com/~mortis