ViaVoice Stability Success was Re: SourceForge CVS

["T. V. Raman" <raman@xxxxxxxxxxx>]

For newer Viavoices you should *not* use the eci.ini in the
emacspeak distrib; you should be using the one the RPMs place in
/var/...

and for this you should set env var ECIINI 
appropriately; I have it set to 
/var/opt/IBM/ibmtts/cfg/eci.ini

if you use the older eci.ini with the new engine, you will see
unpredictable behavior because I believe there were some changes
to voice params and possibly to phonemes as well.


>>>>> "Tim" == Tim Cross <tcross@xxxxxxxxxxx> writes:
    Tim> Hi Lukas, Yes, there are some characters which will
    Tim> crash ViaVoice every time.  Actually, I was thinking
    Tim> about these today as I'd forgotten I was going to put a
    Tim> filter in the script to remove them prior to them being
    Tim> passed to ViaVoice. I thought I'd kept a copy, but
    Tim> cannot find one. Do you still have the two sequences as
    Tim> I cannot quite remember what they were. I'll put a regex
    Tim> in the cleanup function of outloud and send a patch to
    Tim> Raman.
    Tim> 
    Tim> With respect to stability - I'm totally blown away at
    Tim> how stable ViaVoice is on both my systems now. I've been
    Tim> running this one from home now for over a day without a
    Tim> single crash! The one at work ran all day today without
    Tim> a single crash as well. The things I did were
    Tim> 
    Tim> 1. Changed the call in atcleci.cpp to the one using _max
    Tim> (I've not done a CVS update, but believe Raman has fixed
    Tim> this in the CVS version.
    Tim> 
    Tim> 2. Used a simple utility which gave me some of my cards
    Tim> HW parameters and set my .asoundrc file based on some of
    Tim> the values from that. I will post that utility to the
    Tim> list once I've cleaned it up and made it a bit more user
    Tim> friendly.
    Tim> 
    Tim> 3. Replaced the eci.ini file which is in the
    Tim> linux_outloud directory with one I generated using the
    Tim> inigen utility which comes with Viavoice. I suspect this
    Tim> may have contributed to the stability of the system. the
    Tim> command for producing the eci.ini file is
    Tim> 
    Tim> /opt/IBM/ibmtts/bin/inigen /opt/IBM/ibmtts/lib/eng50.so
    Tim> /tmp
    Tim> 
    Tim> This will put a new eci.ini file in the /tmp directory,
    Tim> which I then copied to the linux-outloud directory. Note
    Tim> that as I'm using the english british version, the
    Tim> shared library is eng50.so. If your using the US english
    Tim> version, it is enu50.so. The format of the eci.ini file
    Tim> created this way is slightly different from the one in
    Tim> the linux-outloud directory, which looks like one from
    Tim> the older ViaVoice version. The header looks like
    Tim> 
    Tim> [1.1] Path=/opt/IBM/ibmtts/lib/eng50.so Version=5.0
    Tim> Concatenative=1.0 CallbackFlag=0x3f ...  ...
    Tim> 
    Tim> The header of the older eci.ini file is
    Tim> 
    Tim> [1.0] Path=enu50.so Version=5.0 ...  ...
    Tim> 
    Tim> to what extent this affects stability I don't know for
    Tim> sure yet. I will do some experiments and see. However,
    Tim> the different header number and 'CallbackFlag are
    Tim> interesting.
    Tim> 
    Tim> Anyway, hope this helps others get ViaVoice very
    Tim> stable. I cannot believe how well this is working now -
    Tim> its the most reliable solid and responsive software TTS
    Tim> I've had so far. I'm even finding character echo is
    Tim> keeping up with my typing better than any of the other
    Tim> TTS engines I've used. I'm using an emacspeak "speed" of
    Tim> 95.
    Tim> 
    Tim> Tim
    Tim> 
    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"
    >> 
    Tim>
    >> -----------------------------------------------------------------------------
To unsubscribe from the emacspeak list or change your address on
    Tim> the emacspeak list send mail to
    Tim> "emacspeak-request@xxxxxxxxxxx" with a subject of
    Tim> "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"