[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SourceForge CVS

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


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@gmx.net> 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@cs.vassar.edu" 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@cs.vassar.edu" with a subject of
>     Lukas> "unsubscribe" or "help"
> -- 
> Best Regards,
> --raman
> Email:  raman@users.sf.net
> WWW:    http://emacspeak.sf.net/raman/
> AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
> 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@cs.vassar.edu" with a
subject of "unsubscribe" or "help"

Emacspeak Files | Subscribe | Unsubscribe | Search