Re: [SpeechIO-12] speechd v0.39

[Kyle Burton <mortis@voicenet.com>]

I'll address these responses in an email shortly, I just wanted you to know
that I'm in the process of heavily modifying the package (.tar.gz file)
based on 0.45.  I'm adding a Makefile, and pod documentation to the two
scripts in the archive.  Where should I send my changes?  I'm going to be
sending a .tar.gz file...should I attach it to the list?


k

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

On Mon, 9 Aug 1999, Darxus wrote:

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