Bug#848016: brltty-espeak: very monotonous speech and noticable delays in speech output
Samuel Thibault <sthibault@debian.org> schrieb am 10.01.2017, 22:18 +0100:
>Eric Scheibler, on Sun 08 Jan 2017 09:05:09 +0100, wrote:
>> 1. The monotonous speech output persists.
>
>I dug a bit and found the issue, reported upstream, and have uploaded a fixed version.
Confirmed.
>> 2. The delay after muting the screen reader is still there too (used the shift key for brltty)
>
>Err, but is shift really supposed to shut brltty up? Without using the
>keycapture feature, brltty can't detect shift presses. This is the same
>with espeak and espeak-ng.
By default, brltty maps "MUTE" to the control keys. I've also mapped it to the shift keys (better to
reach). Both keys work as expected, except the delay on espeak-ng. But anyway, the mute function
was just an example. I thought, that it would be easy to reproduce.
>> Instead the speech output overlaps during fast cursor navigation. Therefore a fast line-by-line
>> navigation still is not possible. I even think, that it's a bit worse now.
>
>Mmm, when I try espeak and espeak-ng I don't really see a difference
>here.
This still happens with espeak version 1.49.0+dfsg-5.
I think, that the mute delay and overlapping belong to the same problem. It seems, that the
espeak-ng module needs too long to clean the current speech buffer. Or in other words: the time
between the call to cancel speaking and the actual stop of speech is much higher then before.
For mute, this results in a noticeable delay, in which espeak still talks, although it should be
canceled already. And the overlapping occurs, cause thread 2 already speaks the new line while
thread 1 is still talking.
Eric
Reply to: