Re: Sometimes bad responsiveness with outloud and alsa 1.0.16

["Tim Cross" <tcross@xxxxxxxxxxx>]

Hi Lukas,

I've applied your patch. Things do appear to be better on the machine that
was having problems with rspect to responsiveness. I will use it over the
next few days and see how it works out. If I get any problems, I'll let you
know. 

thanks for looking into this. 

Tim


Lukas Loehrer writes:
 > 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"
 > 

-- 
Tim Cross
tcross@xxxxxxxxxxx

There are two types of people in IT - those who do not manage what they 
understand and those who do not understand what they manage.

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