Re: [SpeechIO-12] speechd v0.39

[Darxus <darxus@Op.Net>]

Kyle: you're still sending multiple messages :)


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.  

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.

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.  

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 ?

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 ?

On Mon, 9 Aug 1999, Kyle Burton wrote:

> The only other issues that we could control over a straight FIFO would be
> for multiple writers -- a device can control the writers so that only 1 can

> Another possibility would be to have the device driver break things by
> newline, and multiplex the input that way -- i.e. multiple simultaneous 
> writers could have the file open, but when they write to it, the writes
> are managed atomicly using lines as the atoms.  So you'd get a mix of lines,
> but never a hash/splitting of lines of text.  This also has issues with
> a process writing text, and not the end of line causing all the others to
> remain blocked.

I'd prefer this type of ordering, the way the fifo handles it -- one line
at a time, in the order in which they were written.

> The device driver code shields the reading process from writers who close
> the device.  The reader doens't receive the EOF when writers close the
> device file.  This allows us to open the device file (for which we were
> using a FIFO for before) and never close it, because now we don't need to.
> 
> Is this the kind of solution we were looking for?

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.

__________________________________________________________________
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