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

Re: [SpeechIO-12] speechd v0.39



On Mon, 9 Aug 1999, Kyle Burton wrote:

> 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.

I don't think sleeping a second or 2 whenever a program closes it's write
connection to /dev/speech will be all that bad.

> > 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

is "cat file >> /dev/speech" that much more complicated than "cat file >
/dev/speech" ?

> 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 was never overly concerd about control statements, but that would be
neat.  Didn't realize you could send them seperatly though the same file.  

> > 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?  

Agreed, but is it actually broken ?

You just made me think that if...

* program A writes text to /dev/speech, then closes the connection
  (writing an EOF)
* program B appends more text to /dev/speech

When festival gets to the EOF from program A, with the text from program B
be lost ?  Or (with the while (1) { open {while ($text = <FIFO>) {write}
close} ) will it just close, reopen, and continue reading just after the
EOF ?

So is it broken (actually loosing data, or anything else) ?  Or just
slightly uneligant (opening & closing, without loosing anything, rarely) ?


I am getting so much out of this conversation :)
__________________________________________________________________
PGP fingerprint = 03 5B 9B A0 16 33 91 2F  A5 77 BC EE 43 71 98 D4
            darxus@op.net / http://www.op.net/~darxus
                         Far Beyond Reason