Re: SourceForge CVS

[Lukas Loehrer <listaddr1@xxxxxxxxxxx>]

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"