Re: Sometimes bad responsiveness with outloud and alsa 1.0.16
Lukas Loehrer <listaddr1 <at> gmx.net>
2008-04-08 16:42:26 GMT
I am pretty sure this is a regression in libasound 1.0.16. Or at
least, the blocking semantics of some api functions must have changed
in a way not expected by the outloud speech server. I doubt it will be
fixable by duning the .asoundrc file. The problem is that I still
cannot produce a useful small test case to reproduce and document the
For now, I would stick with libasound 1.0.15 on machines that are
needed to get work done.
Best regards, Lukas
Tim Cross writes ("Re:Sometimes bad responsiveness with outloud and alsa 1.0.16"):
> Just a followup on this. I have had one box with an Audigy 4 card that is
> really playing up. I get really slow character echo and often words spoken
> twice. I've spent hours trying to get a better asoundrc file, but with no
> On another box, running an older SB Live card, I was also getting som
> eproblems, but nowwhere as bad.
> I've found that under both Debian testing and unstable, I still need a
> .asoundrc file. Without one, I get unusable output from outloud.
> I've also noticed I'm getting segmentation faults from outloud on both
> systems. Not sure why yet.
> I removed all the sound stuff I didn't need, such as jackd, pulseaudio,
> portaudio and other sundry packages installed as dependencies for various
> other programs I've tried out. This appears to have fixed the problem on
> one box. I've yet to try it on the other.
> The better performance now is on the Debian unstable box with the SB Live
> card. The Debian testing box running with an Audigy 4 card is nearly
> unusable because character echo is really slow (other spects of the speech
> are fine).
> Lukas Loehrer writes:
> > 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 <at> cs.vassar.edu" with a
> > subject of "unsubscribe" or "help"
> Tim Cross
> tcross <at> 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.