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

Re: Sometimes bad responsiveness with outloud and alsa 1.0.16



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@cs.vassar.edu" 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@cs.vassar.edu" with a
 > subject of "unsubscribe" or "help"
 > 

-- 
Tim Cross
tcross@rapttech.com.au

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@cs.vassar.edu" with a
subject of "unsubscribe" or "help"



If you have questions about this archive or had problems using it, please send mail to:

priestdo@cs.vassar.edu No Soliciting!

Emacspeak List Archive | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 | 2001 | 2000 | 1999 | 1998 | Pre 1998

Emacspeak Files | Emacspeak Blog | Search the archive