Re: SourceForge CVS

[Tim Cross <tcross@xxxxxxxxxxx>]

Hi Lukas,

Thanks for that, you saved me a bit of time. In fact, after a little
thought and a bit of judicious scanning of the alsa docs (I'm new to
alsa), plus a little very simple utility program I wrote to dump out
my cards hw parameters, I've managed to get things working really well
in just over an hours work over lunch. 

Here is what I've discovered:

The snd_pcm_hw_params_get_buffer_time will work if you have saved your
earlier settings prior to calling it. I believe what is happening is
that once you have selected the mode, format, rate etc, then the call
will work. I guess by the time you have selected the other parameters,
the possible buffer size choices have been constrained enough for the
function to identify a specific size.

I guess we could do one of two things. Put a call to set the
parameters prior to calling this function or test the return code from
snd_pcm_hw_params_get_buffer_time and if its less than 0 then call
snd_pcm_hw_params_get_buffer_time_max. The problem with the second
solution, as you pointed out, is that you may end up with an overly
large buffer and get underruns etc. However, I did notice the result
from calling the function after having set and saved the earlier
values seems very small (16), especially when compared tot he max value.

Something I did notice when looking at the code is there are a couple
of if statements which don't appear to be really doing anything - I'm
guessing they are an artifact from when Raman was developing the code.
For example 

  if (buffer_time == 0 && buffer_frames == 0) {

both buffer_time and buffer_frames are initialized to 0 and this is
the first time they are referenced, so the test is always true. I've
not removed them yet, but unless I'm missing something, there doesn't
seem to be any reason for them to be there. 

I wrote a very simple utility which dumps out my cards hardware
settings. Using the values from this, I created a new .asoundrc file
which appears to have fixed all my underrun problems. I'm going to
clean it up a bit and send it to the list just in case someone else
finds it useful. 

One very good thing about the new atcleci.cpp code is that it seems *a
lot* more stable. In fact, rather than the server dying every few
minutes, it has not died for me in nearly an hour so far. I'm thinking
this could be due to your suggested additions to add the functions to
free up resources correctly - the crashes could have been due to
resource limitations. At any rate, its working remarkably well now. 

Another interesting discovery I made is that the ViaVoice eci.ini file
appears to be slightly different in current versions than the older
one. I decided to generate a new one using the initgen utility just to
check there had been no changes in later versions of ViaVoice. The one
generated by initgen has some extra header fields not in the original
i.e.

[1.1]
Path=/opt/IBM/ibmtts/lib/eng50.so
Version=5.0
Concatenative=1.0
CallbackFlag=0x3f
...
...

regards,

Tim

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