Samuel Thibault <sthiba...@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
