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 "email@example.com" with a > subject of "unsubscribe" or "help" > ----------------------------------------------------------------------------- To unsubscribe from the emacspeak list or change your address on the emacspeak list send mail to "firstname.lastname@example.org" with a subject of "unsubscribe" or "help"
If you have questions about this archive or had problems using it, please send mail to:email@example.com No Soliciting!
Emacspeak List Archive | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 | 2001 | 2000 | 1999 | 1998 | Pre 1998
Emacspeak Files | Emacspeak Blog | Search the archive