[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:


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.

Join espeak-ng@groups.io to automatically receive all group messages.