Topics

[espeak-ng:master] reported: sluggish speech interruption #github

espeak-ng@groups.io Integration <espeak-ng@...>
 

[espeak-ng:master] New Comment on Issue #172 sluggish speech interruption
By sthibaul:

Hello,

I have dug a bit more into the issue our users are getting, and it happens that it seems like a bug in ALSA, in that snd_pcm_drop doesn't actually drop the PCM data from buffers, see for instance http://stackoverflow.com/questions/15826155/alsa-snd-pcm-drop-is-not-clearing-complete-buffer . Some users have indeed reported real overlapping of speech: the last bits of PCM is simply restarted along the new bits of PCM... This is possibly dependent on the actual ALSA driver.

What espeak was doing which avoided the issue was to actually shut down the PCM object, and that indeed manages to completely flush the ALSA buffers and thus avoids the issue. I have attached here fix-cancel.txt the corresponding fix. It brings back part of f9ab812 : reintroduce close_audio, but also a new open_audio, so that the cancel code can close/open the audio stream to make sure it gets flushed.

I have left a FIXME in the patch: there is still one case which is not fixed, it's when one wants to cancel the very end of an ongoing speech. In that case espeak-ng has finished producing the samples and has pushed the last bits to ALSA and is just blocked inside the audio_object_drain() call. If the user calls cancel here, the ongoing audio will not be interrupted. Depending on the ALSA setup, that might be more or less long. Instead of just draining, espeak-ng should instead drain with a timeout, so as to get back control periodically in order to check my_stop_is_required from times to times (e.g. 60ms). That's however not supported by pcaudiolib yet, so it's not a simple fix, I won't be able to do that for Debian Stretch.

espeak-ng@groups.io Integration <espeak-ng@...>
 

[espeak-ng:master] New Comment on Issue #172 sluggish speech interruption
By rhdunn:

Hi Samuel,

Thanks for investigating this further. I have pushed a different implementation of my original fix and your fix-cancel.txt patch to call audio_object_flush instead of close/open. The audio_object_flush implementation will be fixed to resolve this issue.

is it just ALSA that is the issue, or is pulseaudio affected as well?

espeak-ng@groups.io Integration <espeak-ng@...>
 

[espeak-ng:master] New Comment on Issue #172 sluggish speech interruption
By CMB:

A couple quick points.

There are two places where espeak-ng handles stop requests. One is in close_stream, the other is at the bottom of the main loop in say_thread. As far as I can tell, the one in close_stream is rarely or never exercised. So I patched fifo.c to call audio_object_flush in say_thread.

Second, in speech.c, audio_object_flush gets called in espeak_ng_Cancel. This call happens in a thread other than say_thread, which is the one doing the audio handling. pcaudiolib isn't guaranteed to be threadsafe, so I don't think we can call audio_object_flush there at all. What is that going to do to responsiveness?

There are two branches on my fork https://github.com/CMB/espeak-ng. One is stoprequest, which adds audio_object_flush to say_thread. The other branch is named threadsafe, and it has a patch to remove the flush call from speech.c as well as the stop request patch.