Re: Sometimes bad responsiveness with outloud and alsa 1.0.16

["Lukas Loehrer" <listaddr1@xxxxxxxxxxx>]

Hi all,

I am replying to a message by myself from a few months ago about bad
responsiveness with the outloud speech server after updating to
libasound 1.0.16-2 (see quoted message at the bottom for details). I
spend the better part of yesterday debuggin and eventually fixing the
problem. I will give some details about the solution below, but if you
are experienceing similar issues, you may just want to give the
following patch a try:

http://homepage.hispeed.ch/loehrer/emacspeak.html

If you try it, please report back about the outcome. Because I noticed
the problem after an alsa update, I assumed it was alsa related. It
turns out the problem was there before, only in a much milder form.
The alsa upate just happened to make it show much more strongly, the
exact reason of which is stil unclear to me. Also, it occured only on
one of my machines.

Technical details follow:

Basically, after the outloud speech server has passed a chunk of text to be
synthesize to ibmtts, it repeatedly calls eciSpeaking() in a loop to
drive the synthesis process. Each call to eciSpeaking() will cause the
installed callback to be called with some newly synthesized audio
data. In the same loop the select() function is called to check
whether there is new data on stdin from emacspeak in order to be able
to react to stop commands. This design assumes that each call to
eciSpeaking() will return fairly quickly so that we can check for stop
commands regularly. Usually, this seems to be the case and
eciSpeaking() returns after a single invokation to the callback.
However, not so on the prolematic machines. Especially towards the end
of the synthesis of a chunk of text, eciSpeaking() would call the
callback many times andn thus not give the select() call a chance to
run. This is what caused the very noticeable delays when trying to
stop speech. According to the ibmtts docs, this behavior is to be
expected.

To fix the problem, I introduced a counter for the number of callback
invokations per eciSpeaking() call and return eciDataNotProcessed from
the callback when this number exceeds a certain threshold. This causes
eciSpeaking() to return and it will supply the same data to the
callback again on a later call. This fixed the problem with
responsiveness.

Unfortunately, This caused another problem to show up : After
returning eciDataNotProcessed from the callback, a subsequent call to
eciStop() will often block forever and thus hang the outloud speech
server. This may be a bug in ibmtts. I worked around it by calling
eciSpeaking() until it returns false before calling eciStop(). During
this, a flag is set that causes the callback to do nothing and simply
return eciDataProcessed. This workaround assumes that the chunks of
text passed to ibmtts are not very large, which seems to be the case
with emacspeak. This is not nice, but I could not think of a better
way to avoid the server hangs.

Wiht these modifications, the outloud speech server has very good
responsiveness and stability again on the prolematic machine. I would
not recommend the patch for inclusion in emacspeak at this point. The
fix to limit the number of callback calls is certainly sound. However
the hack required to work around the second problem clearly is not.
Also, the fix is only needed on one machine so far.

Best regards, Lukas

Lukas Loehrer writes ("Sometimes bad responsiveness with outloud and alsa 1.0.16"):
> 
> On Debian sid with libasound2-1.0.16-2, I am getting very bad
> responsiveness with the outloud speech server in some situations. The
> problem goes away after downgrading to libasound2 1.0.15-3.
> 
> Responsiveness is not generally bad, but only in some situations. The
> problem is easier to see with low speech-rates. The problem is for
> example reproducible in in an info buffer when cycling from links to
> links with the tab key. Voice locking must be enabled.
> 
> 1. Hit tab to jump to a link
> 2. wait a bit until emacspeak is in the middle of reading the actual link text
> 3. Hit tab again to get to the next link
> 
> What should happen: speech should stop imediately and the next link should be read.
> What happens with libasound 1.0.16-2: The text of the first link is read to the end and then the text of the second link is read.
> 
> Similar effects can be observed when moving through code line by line
> and some font-locking is present. 
> 
> I have not yet been able to nail down the problem to a specific alsa
> api call, but it is probably either snd_pcm_writei() or snd_pcm_drop()
> whose behavior must have  changed in a subtle way in 1.0.16. I cannot produce
> a short test case that reproduces the problem, so reporting the bug to
> either Debian or Alsa is difficult. Can anyone reproduce the described
> behavior?
> 
> Best regards, 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"
> 

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