[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 :)
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...
open FIFO, $fifo;
while ($text = <FIFO>)
(send text to festival)
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
$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
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
firstname.lastname@example.org / http://www.op.net/~darxus
Far Beyond Reason