Re: SourceForge CVS

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

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"