Re: ViaVoice Stability Success was Re: SourceForge CVS

[Lukas Loehrer <listaddr1@xxxxxxxxxxx>]

thank you Tim and Raman for your tips on improving viavoice
stability. I have been using a custom eci. ini file for some time
because I use both the German and the American synthesizer. However, I
did not know about the automatically generated file under
/var/opt/IBM/ibmtts/cfg. it contains some additional lines that may be
useful. I have not tested the new atcleci.cpp file together with that
eci.ini enough to make any claims about stability but it works well so far.

The repetition problems on the problematic machine with the turtle
Beach Santa Cruz sound card are still present but not a big problem
for me as they are easily fixed by skipping the buffer size and
sw_params configuration code in atcleci.cpp. At some point, I will
find the exact part of that code that causes this problem.

Best regards, Lukas

T. V. Raman writes ("ViaVoice Stability Success was Re: SourceForge CVS"):
> 
> 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"