ViaVoice Stability Success was Re: SourceForge CVS

[Tim Cross <tcross@xxxxxxxxxxx>]

Hi Lukas,

Yes, there are some characters which will crash ViaVoice every time.
Actually, I was thinking about these today as I'd forgotten I was
going to put a filter in the script to remove them prior to them being
passed to ViaVoice. I thought I'd kept a copy, but cannot find one. Do
you still have the two sequences as I cannot quite remember what they
were. I'll put a regex in the cleanup function of outloud and send a
patch to Raman.

With respect to stability - I'm totally blown away at how stable
ViaVoice is on both my systems now. I've been running this one from
home now for over a day without a single crash! The one at work ran
all day today without a single crash as well. The things I did were

1. Changed the call in atcleci.cpp to the one using _max (I've not
done a CVS update, but believe Raman has fixed this in the CVS
version.

2. Used a simple utility which gave me some of my cards HW parameters
and set my .asoundrc file based on some of the values from that. I
will post that utility to the list once I've cleaned it up and made it
a bit more user friendly. 

3. Replaced the eci.ini file which is in the linux_outloud directory
with one I generated using the inigen utility which comes with
Viavoice. I suspect this may have contributed to the stability of the
system. the command for producing the eci.ini file is

/opt/IBM/ibmtts/bin/inigen /opt/IBM/ibmtts/lib/eng50.so /tmp

This will put a new eci.ini file in the /tmp directory, which I then
copied to the linux-outloud directory. Note that as I'm using the
english british version, the shared library is eng50.so. If your using
the US english version, it is enu50.so. The format of the eci.ini file
created this way is slightly different from the one in the
linux-outloud directory, which looks like one from the older ViaVoice
version. The header looks like

[1.1]
Path=/opt/IBM/ibmtts/lib/eng50.so
Version=5.0
Concatenative=1.0
CallbackFlag=0x3f
...
...

The header of the older eci.ini file is

[1.0]
Path=enu50.so
Version=5.0
...
...

to what extent this affects stability I don't know for sure yet. I
will do some experiments and see. However, the different header number
and 'CallbackFlag are interesting. 

Anyway, hope this helps others get ViaVoice very stable. I cannot
believe how well this is working now - its the most reliable solid and
responsive software TTS I've had so far. I'm even finding character
echo is keeping up with my typing better than any of the other TTS
engines I've used. I'm using an emacspeak "speed" of 95. 

Tim

Lukas Loehrer writes:
 > 
 > I have had some difficulties producing meaninful backtraces from the
 > outloud crashes apparently because the libibmeci.so file is loaded
 > dynamically. I had to first run the outloud tcl script in gdb and then
 > load the core file. I do not fully trus those backtraces. I will try
 > to get to the bottom of this when I have time.
 > 
 > On the other hand, I know for a fact that there are certain strings
 > that crash viavoice in a reproducible way. There was some clown a few
 > weeks ago on the blindcooltech mailing list that was sending mails
 > with those strings in the subject line to crash eloquence on windows
 > which is apparently the same as viavoice because those strings also crashed
 > viavoice under linux immediately. I am only  saying this to make
 > the point that viavoice itself may not be so rock solid after
 > all. That said, I still use it and like it much better then flite
 > because it speaks slightly clearer at high speeds and it gives me
 > multilingual support. This is worth some crashes every now and then.
 > 
 > Best regards, Lukas
 > 
 > T. V. Raman writes ("Re: SourceForge CVS"):
 > > 
 > > and no offence taken, I was just pointing out where it came from.
 > > 
 > > The current version does the safe thing by trying the call that
 > > one should use, followed by the call that one needs to use.
 > > 
 > > Incidentally I also believe you're incorrect in repeatedly
 > > asserting that Viavoice TTS engine has the bugs; that code has
 > > been running a long time in many different environments, and it's
 > > safe to assume that it in fact is not the source of the bugs. The
 > > bugs are in the Linux sound layer which has always been a
 > > second-class citizen on Linux; alsa does a little better in this
 > > regard, but it still has a long way to go 
 > > 
 > > >>>>> "Lukas" == Lukas Loehrer <listaddr1@xxxxxxxxxxx> writes:
 > >     Lukas> I apologize for being a bit slobby in my previous
 > >     Lukas> mail. I was refering to the version of atcleci.cpp
 > >     Lukas> that Tim mentioned in his initial post (version
 > >     Lukas> 21.39), in particular to the call on line 235, which
 > >     Lukas> is actually
 > >     Lukas> 
 > >     Lukas> snd_pcm_hw_params_get_buffer_time
 > >     Lukas> 
 > >     Lukas> and is already changed to the _max version in the
 > >     Lukas> current CVS (21.43). Anyway, no offence was meant at
 > >     Lukas> any time.
 > >     Lukas> 
 > >     Lukas> Best regards, Lukas
 > >     Lukas> 
 > >     Lukas> T. V. Raman writes ("Re: SourceForge CVS"):
 > >     >> 
 > >     >> For the record, the alsa config code in the emacspeak
 > >     >> server is taken from the examples that are in the doxygen
 > >     >> directory of alsa-lib --- so any bugs there are not mine
 > >     >> but directly descended from Alsa
 > >     >> 
 > >     >> >>>>> "Lukas" == Lukas Loehrer <listaddr1@xxxxxxxxxxx> writes:
 > >     Lukas> Hi Tim, A utility for checking out card parameters
 > >     Lukas> will certainly be useful to many peaple here.
 > >     Lukas> 
 > >     Lukas> I believe that the apparently superfluous tests in
 > >     Lukas> alsa_configure are to do automatic parameter selection
 > >     Lukas> by default and if that fails, the user can initialize
 > >     Lukas> some of the variables to a non-zero value and the
 > >     Lukas> automatic setting will be skipped. The use of the
 > >     Lukas> snd_pcm_get_period_time function in the place it is
 > >     Lukas> currently used is most likely a bug however.
 > >     Lukas> 
 > >     Lukas> I also have one machine where the period size is by
 > >     Lukas> default 16, which is far too low for a buffer size for
 > >     Lukas> the eci callback (chunk_size). Choosing chunk_size as
 > >     Lukas> a multiple of the cards period size and about a
 > >     Lukas> quarter of the alsa buffer size has given me good
 > >     Lukas> results. As we ar using interlieaved mode, I believe
 > >     Lukas> that the actual value of the period size is not that
 > >     Lukas> important.
 > >     Lukas> 
 > >     Lukas> By the way, I believe that most crashes I see are due
 > >     Lukas> to bugs in the ViaVoice speech synthesis code. I have
 > >     Lukas> been recording the communication between emacspeak and
 > >     Lukas> outloud to see what could trigger the crashes but have
 > >     Lukas> not yet been able to draw any meaningful conclusions.
 > >     Lukas> 
 > >     Lukas> Best regards, Lukas
 > >     Lukas> 
 > >     >> >> Hi Lukas, > >
 > >     Lukas> Thanks for that, you saved me a bit of time. In fact,
 > >     Lukas> after a little > thought and a bit of judicious
 > >     Lukas> scanning of the alsa docs (I'm new to > alsa), plus a
 > >     Lukas> little very simple utility program I wrote to dump out
 > >     Lukas> > my cards hw parameters, I've managed to get things
 > >     Lukas> working really well
 > >     >> >> in just over an hours work over lunch.  > > Here is
 > >     >> what >> I've
 > >     Lukas> discovered: > > The snd_pcm_hw_params_get_buffer_time
 > >     Lukas> will work if you have saved your > earlier settings
 > >     Lukas> prior to calling it. I believe what is happening is >
 > >     Lukas> that once you have selected the mode, format, rate
 > >     Lukas> etc, then the call > will work. I guess by the time
 > >     Lukas> you have selected the other parameters, > the possible
 > >     Lukas> buffer size choices have been constrained enough for
 > >     Lukas> the > function to identify a specific size.  >
 > >     >> >> I guess we could do one of two things. Put a call to
 > >     >> set >> the >
 > >     Lukas> parameters prior to calling this function or test the
 > >     Lukas> return code from
 > >     >> >> snd_pcm_hw_params_get_buffer_time and if its less than
 > >     >> 0 >> then call >
 > >     Lukas> snd_pcm_hw_params_get_buffer_time_max. The problem
 > >     Lukas> with the second > solution, as you pointed out, is
 > >     Lukas> that you may end up with an overly > large buffer and
 > >     Lukas> get underruns etc. However, I did notice the result >
 > >     Lukas> from calling the function after having set and saved
 > >     Lukas> the earlier > values seems very small (16), especially
 > >     Lukas> when compared tot he max value.  > > Something I did
 > >     Lukas> notice when looking at the code is there are a couple
 > >     Lukas> > of if statements which don't appear to be really
 > >     Lukas> doing anything - I'm > guessing they are an artifact
 > >     Lukas> from when Raman was developing the code.  > For
 > >     Lukas> example > > if (buffer_time == 0 && buffer_frames ==
 > >     Lukas> 0) { > > both buffer_time and buffer_frames are
 > >     Lukas> initialized to 0 and this is > the first time they are
 > >     Lukas> referenced, so the test is always true. I've > not
 > >     Lukas> removed them yet, but unless I'm missing something,
 > >     Lukas> there doesn't > seem to be any reason for them to be
 > >     Lukas> there.  > > I wrote a very simple utility which dumps
 > >     Lukas> out my cards hardware > settings. Using the values
 > >     Lukas> from this, I created a new .asoundrc file > which
 > >     Lukas> appears to have fixed all my underrun problems. I'm
 > >     Lukas> going to > clean it up a bit and send it to the list
 > >     Lukas> just in case someone else > finds it useful.  > > One
 > >     Lukas> very good thing about the new atcleci.cpp code is that
 > >     Lukas> it seems *a > lot* more stable. In fact, rather than
 > >     Lukas> the server dying every few > minutes, it has not died
 > >     Lukas> for me in nearly an hour so far. I'm thinking > this
 > >     Lukas> could be due to your suggested additions to add the
 > >     Lukas> functions to > free up resources correctly - the
 > >     Lukas> crashes could have been due to > resource
 > >     Lukas> limitations. At any rate, its working remarkably well
 > >     Lukas> now.  >
 > >     >> >> Another interesting discovery I made is that the
 > >     >> ViaVoice >> eci.ini
 > >     Lukas> file > appears to be slightly different in current
 > >     Lukas> versions than the older > one. I decided to generate a
 > >     Lukas> new one using the initgen utility just to > check
 > >     Lukas> there had been no changes in later versions of
 > >     Lukas> ViaVoice. The one > generated by initgen has some
 > >     Lukas> extra header fields not in the original > i.e.  > >
 > >     Lukas> [1.1] > Path=/opt/IBM/ibmtts/lib/eng50.so >
 > >     Lukas> Version=5.0 > Concatenative=1.0 > CallbackFlag=0x3f >
 > >     Lukas> ...  > ...  > > regards, > > Tim > >
 > >     Lukas> -----------------------------------------------------------------------------
 > >     >> >> To unsubscribe from the emacspeak list or change your
 > >     >> >> address on the emacspeak list send mail to >>
 > >     >> "emacspeak-request@xxxxxxxxxxx" with a subject of >>
 > >     >> "unsubscribe" or "help" >
 > >     Lukas> 
 > >     Lukas> -----------------------------------------------------------------------------
 > >     Lukas> To unsubscribe from the emacspeak list or change your
 > >     Lukas> address on the emacspeak list send mail to
 > >     Lukas> "emacspeak-request@xxxxxxxxxxx" with a subject of
 > >     Lukas> "unsubscribe" or "help"
 > >     >> 
 > >     >> -- 
 > >     >> Best Regards, --raman
 > >     >> 
 > >     >> 
 > >     >> Email: raman@xxxxxxxxxxx WWW:
 > >     >> http://emacspeak.sf.net/raman/ AIM: emacspeak GTalk:
 > >     >> tv.raman.tv@xxxxxxxxxxx PGP:
 > >     >> http://emacspeak.sf.net/raman/raman-almaden.asc Google:
 > >     >> tv+raman IRC: irc://irc.freenode.net/#emacs
 > >     >> 
 > >     Lukas>
 > >     >> -----------------------------------------------------------------------------
 > > To unsubscribe from the emacspeak list or change your address on
 > >     Lukas> the emacspeak list send mail to
 > >     Lukas> "emacspeak-request@xxxxxxxxxxx" with a subject of
 > >     Lukas> "unsubscribe" or "help"
 > > 
 > > -- 
 > > Best Regards,
 > > --raman
 > > 
 > >       
 > > Email:  raman@xxxxxxxxxxx
 > > WWW:    http://emacspeak.sf.net/raman/
 > > AIM:    emacspeak       GTalk: tv.raman.tv@xxxxxxxxxxx
 > > PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
 > > Google: tv+raman 
 > > IRC:    irc://irc.freenode.net/#emacs
 > > 
 > 
 > -----------------------------------------------------------------------------
 > To unsubscribe from the emacspeak list or change your address on the
 > emacspeak list send mail to "emacspeak-request@xxxxxxxxxxx" with a
 > subject of "unsubscribe" or "help"
 > 

-----------------------------------------------------------------------------
To unsubscribe from the emacspeak list or change your address on the
emacspeak list send mail to "emacspeak-request@xxxxxxxxxxx" with a
subject of "unsubscribe" or "help"