ViaVoice Stability Success was Re: SourceForge CVS

[Tim Cross <tcross@xxxxxxxxxxx>]

For some reason, under Debian using the rpm install, you do not get an
eci.ini file installed. All the software is placed under /opt and
nothing is placed under /var at all. So, in this case you have to run
the inigen utility to get a correct eci.ini file for the later
ViaVoice software.


Tim

T. V. Raman writes:
 > 
 > 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"
 > 

-----------------------------------------------------------------------------
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"