Re: audio/flite: remove flush in play_wave()

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	hello.  Well, that's one of the reasons I run this old code; it took a while for me to get
it to work in the first place, trying to get an understanding of how all the pieces fit
together, or should fit together.  Then, once working, it was incredibly unstable, crashing at
the most inconvenient moments.  In the end, there weren't that many patches needed to make it
work reliably, but I seem to remember spending a lot of time playing with the threading and
becoming convinced that the threading was the source of my inability to shut the thing up on
demand.  I don't know if it's helpful, but I remember thinking, as I was iterating through the
process, that the wave thread, we're talking about in eflite here, was a long running thread
which took text from the input thread and rendered the wave output.  Instead, the text thread,
which is the main thread, takes text from the socket and, if there is a wave thread running,
feeds that text to the wave thread.  However, if there is no wave thread running, it starts a
new wave thread and feeds text to it.  Once the wave thread has rendered the text it receives,
it terminates.  It doesn't wait around to see if mor text might be incoming.  The reason I'm
mentioning all of this is because, essentially, all of Flite is running inside of that wave
thread, including the handling of the sound device.  I don't remember  clearly how the plumbing
works between the receiving of the silence command from yasr by eflite and the sessation of
speech, but I do remember running into some synchronization issues between what the sound
device was doing and what Flite thought the sound device was doing, which is what lead me to
the pach you started with.  At the end of the day, there can be no daylight between what Flite
thinks is happening with the sound device and what it's actuallyu doing, otherwise, you'll get
effects like lost speech, delayed silences, etc.  It's important to note that there is no real
flow control mechanism between Yasr and eflite.  That means, it's possible for Yasr to feed
more text to eflite than it can handle in a timely manner.  When that happens, you'll get lost
speech as well.   In that case, however, Yasr can tel eflite to stop what it's doing and speak
the text it's sending now and drop everything else.  In other words, it's okay for the
connection between Yasr and eflite to be a bit lossy, but it's not okay for the connection
between the text thread and the wave thread of eflite to be lossy.  In the process of building
this house of cards so many years ago, I found that there were times when it was hard to tell
where the loss was occurring.  I haven't looked at the newer version of Flite, so don't know
what's different, but I wonder what you mean when you say eflite doesn't work with the newer
version of Flite?  Is the actual interface different, or does Flite behave in a manner that
eflite doesn't expect?

Anyway, I hope these observations are helpful.
-thanks
-Brian