[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Speech-30] fixes and such
On Wed, 4 Aug 1999, Michael wrote:
> Okay...there are a lot of changes that I made...some of them add new
> problems. It'll keep us busy ;p
> This is a unified diff patch against v0.29.
> Apply using 'patch < wm29to30.patch'
> Going down through my patch, here are some of the changes...:
> First of all...I think I found a problem in tts_file. Currently, the
> use_festival_tts_file sub will send a command EVERY two seconds to the
> server, regardless of whether or not text has been sent to the FIFO. Upon
> receiving a tts_file request, the server waits until there is some text to
> parse in the FIFO. This, I believe, overloads the server with commands
> that it will probably never reach, so, I changed the default behavior to
> use Say_Text by default.
I was guessing that it just blocked on the 1st, but I also noticed that it
doesn't seem to be possible to write to /dev/speech while festival is
speaking using the tts_file method, so I was going to switch the default
> Removed a ".wav player =..." option...I have no idea what it did...but, it
> wasn't in use.
A relic from when speechd used festival_client, which didn't have a tts
(text to speech) mode, and the closest I could get was a sound file. It
did, in fact, require a .wav player once.
Connecting directly to the festival server is *much* cleaner :)
I could upload some of the really old versions if you'd like to see how
nasty it was :)
> Fixed the regex expression that escapes quotes and backslashes...
What was wrong with it ? I'm very curious, as I consider that a security
concern. I admit I don't fully comprehend just how bad the possibilities
are, but we are dealing with a programming language (what's it called...
based on lisp...) and potentially bad stuff could happen if somebody could
/msg you something in IRC that would escape out of the SayText function
and execute some other function.
> I added sanity checks for $handle, before it writes to it. If it doesn't
> find $handle, then it will try &connect_to_festival.
> The 'or die' for use_festival_tts_file was in the wrong place...corrected.
Cool. I really gotta get through this camel book :)
> Finally...the broken pipe problem. Yesterday, I added a 'recv' function
> to maybe see if the festival server was saying something before it
> disconnected speechd (something like an idle timeout function). I'm not
> sure...but...I think it stopped the disconnections. Does anyone know if
> there's an incoming data buffer that needs to be cleared occasionally?
> I'm thinking that was the problem...the recv buffer just overflowed.
> So...it now recv's 50 bytes of data each loop.
Soo... what's the data ? I'd assume you weren't getting anything because
you didn't say what you got, but at the same time, you believe there was
some overflow of stuff being backed up.... ?
> And one problem that kinda annoys me...is that when we run festival, it
> puts it in the background, and stays alive even when speechd dies. Do we
> have to put it in the background or do we even need to run it? It would
> be much easier to keep the user responsible for running it.
I suppose we could fork it instead of backgrounding it ? Or we could try
to do a "killall festival" when speechd exits. I basically added it to
simplify the use of speechd. And I don't think it's gonna kill anybody
as it is.
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