Re: Sometimes bad responsiveness with outloud and alsa 1.0.16

["T. V. Raman" <raman@xxxxxxxxxxx>]

Lukas --
Thanks for chasing this down. 

The only times that emacspeak  is likely to pass a large chunk of
text to the TTS layer are:

0)  you accidentally speak a region of text that is base64
encoded

1)  You speak a large amount of shell output and for some reason
the clause delimiter doesn't break up your output correctly 



>>>>> "Lukas" == Lukas Loehrer <listaddr1@xxxxxxxxxxx> writes:
    Lukas> Hi all, I am replying to a message by myself from a
    Lukas> few months ago about bad responsiveness with the
    Lukas> outloud speech server after updating to libasound
    Lukas> 1.0.16-2 (see quoted message at the bottom for
    Lukas> details). I spend the better part of yesterday
    Lukas> debuggin and eventually fixing the problem. I will
    Lukas> give some details about the solution below, but if you
    Lukas> are experienceing similar issues, you may just want to
    Lukas> give the following patch a try:
    Lukas> 
    Lukas> http://homepage.hispeed.ch/loehrer/emacspeak.html
    Lukas> 
    Lukas> If you try it, please report back about the
    Lukas> outcome. Because I noticed the problem after an alsa
    Lukas> update, I assumed it was alsa related. It turns out
    Lukas> the problem was there before, only in a much milder
    Lukas> form.  The alsa upate just happened to make it show
    Lukas> much more strongly, the exact reason of which is stil
    Lukas> unclear to me. Also, it occured only on one of my
    Lukas> machines.
    Lukas> 
    Lukas> Technical details follow:
    Lukas> 
    Lukas> Basically, after the outloud speech server has passed
    Lukas> a chunk of text to be synthesize to ibmtts, it
    Lukas> repeatedly calls eciSpeaking() in a loop to drive the
    Lukas> synthesis process. Each call to eciSpeaking() will
    Lukas> cause the installed callback to be called with some
    Lukas> newly synthesized audio data. In the same loop the
    Lukas> select() function is called to check whether there is
    Lukas> new data on stdin from emacspeak in order to be able
    Lukas> to react to stop commands. This design assumes that
    Lukas> each call to eciSpeaking() will return fairly quickly
    Lukas> so that we can check for stop commands
    Lukas> regularly. Usually, this seems to be the case and
    Lukas> eciSpeaking() returns after a single invokation to the
    Lukas> callback.  However, not so on the prolematic
    Lukas> machines. Especially towards the end of the synthesis
    Lukas> of a chunk of text, eciSpeaking() would call the
    Lukas> callback many times andn thus not give the select()
    Lukas> call a chance to run. This is what caused the very
    Lukas> noticeable delays when trying to stop
    Lukas> speech. According to the ibmtts docs, this behavior is
    Lukas> to be expected.
    Lukas> 
    Lukas> To fix the problem, I introduced a counter for the
    Lukas> number of callback invokations per eciSpeaking() call
    Lukas> and return eciDataNotProcessed from the callback when
    Lukas> this number exceeds a certain threshold. This causes
    Lukas> eciSpeaking() to return and it will supply the same
    Lukas> data to the callback again on a later call. This fixed
    Lukas> the problem with responsiveness.
    Lukas> 
    Lukas> Unfortunately, This caused another problem to show up
    Lukas> : After returning eciDataNotProcessed from the
    Lukas> callback, a subsequent call to eciStop() will often
    Lukas> block forever and thus hang the outloud speech
    Lukas> server. This may be a bug in ibmtts. I worked around
    Lukas> it by calling eciSpeaking() until it returns false
    Lukas> before calling eciStop(). During this, a flag is set
    Lukas> that causes the callback to do nothing and simply
    Lukas> return eciDataProcessed. This workaround assumes that
    Lukas> the chunks of text passed to ibmtts are not very
    Lukas> large, which seems to be the case with emacspeak. This
    Lukas> is not nice, but I could not think of a better way to
    Lukas> avoid the server hangs.
    Lukas> 
    Lukas> Wiht these modifications, the outloud speech server
    Lukas> has very good responsiveness and stability again on
    Lukas> the prolematic machine. I would not recommend the
    Lukas> patch for inclusion in emacspeak at this point. The
    Lukas> fix to limit the number of callback calls is certainly
    Lukas> sound. However the hack required to work around the
    Lukas> second problem clearly is not.  Also, the fix is only
    Lukas> needed on one machine so far.
    Lukas> 
    Lukas> Best regards, Lukas
    Lukas> 
    Lukas> Lukas Loehrer writes ("Sometimes bad responsiveness
    Lukas> 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"
    >> 
    Lukas> 
-----------------------------------------------------------------------------
To unsubscribe from the emacspeak list or change your address on
    Lukas> the emacspeak list send mail to
    Lukas> "emacspeak-request@xxxxxxxxxxx" with a subject of
    Lukas> "unsubscribe" or "help"

-- 
Best Regards,
--raman

      
Email:  raman@xxxxxxxxxxx
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@xxxxxxxxxxx
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

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