[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
            darxus@op.net / http://www.op.net/~darxus
                         Far Beyond Reason