Re: SourceForge CVS

[Lukas Loehrer <listaddr1@xxxxxxxxxxx>]

I apologize for being a bit slobby in my previous mail. I was refering
to the version of atcleci.cpp that Tim mentioned in his initial post
(version 21.39), in particular to the call on line 235, which is
actually

snd_pcm_hw_params_get_buffer_time

and is already changed to the _max version in the current CVS
(21.43). Anyway, no offence was meant at any time.

Best regards, 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
> 

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