Bug#848016: brltty-espeak: very monotonous speech and noticable delays in speech output

[Eric Scheibler]

Samuel Thibault  schrieb am 15.01.2017, 15:36 +0100:
>Eric Scheibler, on Fri 13 Jan 2017 13:04:24 +0100, wrote:
>> I'am not absolutely sure about that. Could you upload a new version with a 
>> default value of 20 or
>> even 10 ms just for testing purposes?
>
>I have uploaded packages on https://people.debian.org/~sthibault/tmp/
>which use the value from the ESPEAK_NG_BUFLEN environment variable, i.e.
>you run
>
>ESPEAK_NG_BUFLEN=10 brltty -s es blabla...
>
>to set to 10ms. I don't think it will change much the feeling you have.

You were right - it doesn't change much if at all.

Bug#848016: brltty-espeak: very monotonous speech and noticable delays in speech output

[Samuel Thibault]

Hello,

Eric Scheibler, on Fri 13 Jan 2017 13:04:24 +0100, wrote:
> Samuel Thibault  schrieb am 12.01.2017,  3:50 +0100:
> >Samuel Thibault, on Thu 12 Jan 2017 03:27:24 +0100, wrote:
> >> I'm very surprised to see this 200 value, which means 200ms, while
> >> studies have shown that "interactivity" is usually seen bad by humans
> >> beyond 100ms.
> >> 
> >> One thing we can do for Stretch is to reduce this value to something
> >> acceptable. A low value make espeak-ng more CPU-intensive, but that
> >> shouldn't be too harmful.
> >
> >I have uploaded a -6 version with 50ms as default. I couldn't notice
> >a difference between 50ms and 20ms or 10ms, while being much less
> >CPU-intensive, and that seems coherent with the result of the studies :)
> 
> Installed version 1.49.0+dfsg-6. The delay/overlapping is still there.

Ok. I believe this is another issue, which I'll talk about espeakup too.

> I'am not absolutely sure about that. Could you upload a new version with a 
> default value of 20 or
> even 10 ms just for testing purposes?

I have uploaded packages on https://people.debian.org/~sthibault/tmp/
which use the value from the ESPEAK_NG_BUFLEN environment variable, i.e.
you run

ESPEAK_NG_BUFLEN=10 brltty -s es blabla...

to set to 10ms. I don't think it will change much the feeling you have.
More to come in a further mail.

> In general espeak-ng is much more responsive than the old espeak package

I believe that's actually the culprit of the problem, more in the coming
mail :)

> and without the overlapping it would make for a much better user
> experience.

Good :)

Samuel

Bug#848016: brltty-espeak: very monotonous speech and noticable delays in speech output

[Eric Scheibler]

Samuel Thibault  schrieb am 12.01.2017,  3:50 +0100:
>Samuel Thibault, on Thu 12 Jan 2017 03:27:24 +0100, wrote:
>> I'm very surprised to see this 200 value, which means 200ms, while
>> studies have shown that "interactivity" is usually seen bad by humans
>> beyond 100ms.
>> 
>> One thing we can do for Stretch is to reduce this value to something
>> acceptable. A low value make espeak-ng more CPU-intensive, but that
>> shouldn't be too harmful.
>
>I have uploaded a -6 version with 50ms as default. I couldn't notice
>a difference between 50ms and 20ms or 10ms, while being much less
>CPU-intensive, and that seems coherent with the result of the studies :)

Installed version 1.49.0+dfsg-6. The delay/overlapping is still there. But 
maybe it's a bit better.
I'am not absolutely sure about that. Could you upload a new version with a 
default value of 20 or
even 10 ms just for testing purposes?

In general espeak-ng is much more responsive than the old espeak package and 
without the overlapping
it would make for a much better user experience.

Bug#848016: brltty-espeak: very monotonous speech and noticable delays in speech output

[Samuel Thibault]

Samuel Thibault, on Thu 12 Jan 2017 03:27:24 +0100, wrote:
> I'm very surprised to see this 200 value, which means 200ms, while
> studies have shown that "interactivity" is usually seen bad by humans
> beyond 100ms.
> 
> One thing we can do for Stretch is to reduce this value to something
> acceptable. A low value make espeak-ng more CPU-intensive, but that
> shouldn't be too harmful.

I have uploaded a -6 version with 50ms as default. I couldn't notice
a difference between 50ms and 20ms or 10ms, while being much less
CPU-intensive, and that seems coherent with the result of the studies :)

Samuel

Bug#848016: brltty-espeak: very monotonous speech and noticable delays in speech output

[Samuel Thibault]

Hello,

Eric Scheibler, on Wed 11 Jan 2017 15:48:39 +0100, wrote:
> 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.

It seems that by trying various sound setup cases, I eventually found
one where audio output isn't actually asynchronous (using ALSA with
snd_pcm_mmap_writei), and thus pcaudiolib gets stuck while pushing
it. It seems to get better by reducing espeak-ng's buffering.

Could you try to rebuild espeak-ng after modifying file
src/libespeak-ng/speech.c in the espeak_ng_InitializeOutput function,
the line

buffer_length = 200;

into for instance

buffer_length = 20;

or some value between e.g. 10 and 200.

I'm very surprised to see this 200 value, which means 200ms, while
studies have shown that "interactivity" is usually seen bad by humans
beyond 100ms.

One thing we can do for Stretch is to reduce this value to something
acceptable. A low value make espeak-ng more CPU-intensive, but that
shouldn't be too harmful.

Samuel

Bug#848016: brltty-espeak: very monotonous speech and noticable delays in speech output

[Samuel Thibault]

Eric Scheibler, on Wed 11 Jan 2017 15:48:39 +0100, wrote:
> I thought, that it would be easy to reproduce.

Never assume that something is easy to reproduce.  When a bug is not
fixed, it means the maintainer doesn't have it :)

> >> 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.

Can you estimate much "too long" it is?  1s? 0.1s? less?  On my box I
don't really see much difference between espeak and espeak-ng.  Do you
have the pulseaudio package installed?

Samuel

Bug#848016: brltty-espeak: very monotonous speech and noticable delays in speech output

[Eric Scheibler]

Samuel Thibault  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

Bug#848016: brltty-espeak: very monotonous speech and noticable delays in speech output

[Samuel Thibault]

Samuel Thibault, on Tue 10 Jan 2017 22:18:53 +0100, wrote:
> Mmm, when I try espeak and espeak-ng I don't really see a difference

Put another way, with version -5 containing my latest monotonous fixes,
I am not aware of regressions any more compared to espeak (except the
debian installer which needs an espeakup-udeb rebuild).

Samuel

Bug#848158: Bug#848016: brltty-espeak: very monotonous speech and noticable delays in speech output

[Samuel Thibault]

Control: tags -1 + pending

Hello,

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.

Samuel

Bug#848016: brltty-espeak: very monotonous speech and noticable delays in speech output

[Samuel Thibault]

Hello,

Eric Scheibler, on Sun 08 Jan 2017 09:05:09 +0100, wrote:
> 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.

> 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.

> Just for the record: I also tried to use orca with the speech dispatcher and 
> its espeak-ng module.
> This works as expected. No delay and overlappings and a normal pronunciation.

Ok, so at least we can keep espeak-ng there.

Samuel

Bug#848016: brltty-espeak: very monotonous speech and noticable delays in speech output

[Eric Scheibler]

Samuel Thibault  schrieb am 08.01.2017,  0:21 +0100:
>Could you try the latest version, 1.49.0+dfsg-4?

I've removed the old espeak packages entirely and installed espeak-ng, 
espeak-ng-data:amd64,
espeak-ng-espeak and libespeak-ng1:amd64 all in version 1.49.0+dfsg-4.

Unchanged:
1. The monotonous speech output persists.
2. The delay after muting the screen reader is still there too (used the shift 
key for brltty)

But the responsiveness of the speech output in general has improved. For 
example deleting a line of
text char-by-char was very slow in the previous version (spoke almost every 
char before deleting
it). This is much more usable now.

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.

Just for the record: I also tried to use orca with the speech dispatcher and 
its espeak-ng module.
This works as expected. No delay and overlappings and a normal pronunciation.

Regards
Eric

Bug#848016: brltty-espeak: very monotonous speech and noticable delays in speech output

[Samuel Thibault]

Hello,

Eric Scheibler, on Mon 02 Jan 2017 22:16:36 +0100, wrote:
> Samuel Thibault  schrieb am 02.01.2017, 20:56 +0100:
> >Can you please test with the latest version libespeak-ng, 1.49.0+dfsg-3?
> 
> Same problem.

Could you try the latest version, 1.49.0+dfsg-4?

Thanks
Samuel

Bug#848016: brltty-espeak: very monotonous speech and noticable delays in speech output

[Eric Scheibler]

Hello Samuel,

Samuel Thibault  schrieb am 02.01.2017, 20:56 +0100:
>Can you please test with the latest version libespeak-ng, 1.49.0+dfsg-3?

Same problem.

First I've updated espeak-ng, espeak-ng-data and libespeak-ng1 to version 
1.49.0+dfsg-3 (unstable).
Then I started brltty from the testing repository (version 5.4-4). The 
monotonous speech output and
delay are still there.

Secondly, I've installed libespeak-ng-dev and libespeak-ng-libespeak-dev from 
unstable (version
1.49.0+dfsg-3) and built brltty from the git master branch with espeak speech 
driver support. Same
result.

Lastly, I've removed libespeak-ng-dev and libespeak-ng-libespeak-dev and built 
brltty against
the old libespeak-dev library from testing (version 1.48.04+dfsg-5) again. This 
still works as
expected.

Eric

Bug#848016: brltty-espeak: very monotonous speech and noticable delays in speech output

[Samuel Thibault]

Hello,

Eric Scheibler, on Fri 23 Dec 2016 12:34:04 +0100, wrote:
> I still can confirm these issues (Debian testing, Brltty 5.4-3 and 
> brltty-espeak 5.4-3).

Can you please test with the latest version libespeak-ng, 1.49.0+dfsg-3?

Samuel

Bug#848016: brltty-espeak: very monotonous speech and noticable delays in speech output

[Eric Scheibler]

Control: reassign 848016 brltty-espeak


I still can confirm these issues (Debian testing, Brltty 5.4-3 and 
brltty-espeak 5.4-3). They also
occur after a fresh installation of Debian testing (minimal installation).  
Especially the speech
delay is a serious problem and should be addressed before the final release.

I currently run Brltty from the git repository (Rev BRLTTY-5.4-135-g9b144929) 
with the
libespeak-dev:amd64 version 1.48.04 package. That combination still works as 
expected (no delay and
no monotonous output).

Every two or three days I encounter a espeak crash. That means, that Brltty 
still works but the
speech output is killed. A simple restart of Brltty fixes that. In summer, when 
this issue occurred
for the first time, that crashes came much more often (about every 5 minutes). 
I don't know, why
that's much better now.

So far I didn't encounter such behavior with the brltty-espeak package from the 
Debian repositories,
which is linked against libespeak-ng. Therefore we may choose between the 
reproducible espeak-ng
problems and the old espeak crashes, which became much less common for no 
apparent reason.

I highly appreciate the espeak-ng development and I hope, that the delay and 
output problems can be
fixed there in time. But at the current situation, we have to find the least 
problematic solution
for the upcoming Debian release. Would the espeak crashes still occur much more 
often, the choice of
course would be, to link against espeak-ng. But under the condition, that the 
espeak crashes now
occur so infrequently, I think, that linking against the old espeak library is 
the less painful
solution for now.

Bug#848016: brltty-espeak: very monotonous speech and noticable delays in speech output

[Sebastian Humenda]

Package: brltty-espeak
Version: 5.4-3
Severity: important

Hi

after an upgrade of brltty-espeak (which links to espeak-ng), the speech output
is very monotonous and all speech rhythm lost, including e.g. breaks for periods
at the end of a sentence.
That makes it hard to listen to it for a longer period. It is likely to be a
brltty-espeak issue, because

espeak-ng -w test.wav "Some longer text, it has proper stressing of 
words."
aplay test.wav

sounds as `espeak -w test.wav ...`, so without any change.

Furthermore, there is a noticeable delay when interrupting speech with e.g. the
control key. This is problematic when scrolling through texts, because some
portion of the old line is spoken before the new text starts. This makes it
impossible for speech-only users to figure out what is actually on the line

I have taken a log with `brltty -ldebug,speech` and have attached  it.

Please let me know if I can provide more information to help resolving this
issue.

Thanks


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (10, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.8.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages brltty-espeak depends on:
ii  brltty 5.4-3
ii  libc6  2.24-7
ii  libespeak-ng1  1.49.0+dfsg-2

brltty-espeak recommends no packages.

brltty-espeak suggests no packages.

-- no debconf information
2016-12-13@09:44:11.261 [brltty] BRLTTY 5.4 rev BRLTTY-5.4 [http://brltty.com/]
2016-12-13@09:44:11.283 [brltty] lock descriptor allocated: 
queue-discarded-elements
2016-12-13@09:44:11.283 [brltty] Protokollierungsausführlichkeit: debug,speech
2016-12-13@09:44:11.284 [brltty] pushed command environment: initial
2016-12-13@09:44:11.284 [brltty] report listener registered: 0: 
handleUpdateBrailleOnline
2016-12-13@09:44:11.285 [brltty] program exit event added: screen-data
2016-12-13@09:44:11.285 [brltty] Arbeitsverzeichnis: /home/swannie
2016-12-13@09:44:11.285 [brltty] Konfigurationsdatei: /etc/brltty.conf
2016-12-13@09:44:11.285 [brltty] Modifizierbares Verzeichnis: /var/lib/brltty
2016-12-13@09:44:11.285 [brltty] Einstellungsdatei: brltty.prefs
2016-12-13@09:44:11.285 [brltty] Verzeichnis mit Schreibzugriff: /var/run/brltty
2016-12-13@09:44:11.285 [brltty] Treiber-Verzeichnis: /lib/brltty
2016-12-13@09:44:11.285 [brltty] Tabellenverzeichnis: /etc/brltty
2016-12-13@09:44:11.306 [brltty] program exit event added: tunes
2016-12-13@09:44:11.306 [brltty] tune thread state change: 0 -> 1
2016-12-13@09:44:11.307 [brltty] tune thread state change: 1 -> 3
2016-12-13@09:44:11.307 [brltty] regions: text=0.0 status=0.0
2016-12-13@09:44:11.307 [brltty] shifts: full=1 half=0 vertical=5
2016-12-13@09:44:11.307 [brltty] checking for text table: 
/etc/brltty/Text/de_DE.ttb
2016-12-13@09:44:11.349 [brltty] checking for text table: 
/etc/brltty/Text/de.ttb
2016-12-13@09:44:11.364 [brltty] compiling text table: /etc/brltty/Text/de.ttb
2016-12-13@09:44:11.364 [brltty] file opened: /etc/brltty/Text/de.ttb fd=8
2016-12-13@09:44:11.364 [brltty] including data file: /etc/brltty/Text/de.ttb
2016-12-13@09:44:11.371 [brltty] file opened: /etc/brltty/Text/ltr-latin.tti 
fd=9
2016-12-13@09:44:11.371 [brltty] including data file: 
/etc/brltty/Text/ltr-latin.tti
2016-12-13@09:44:11.382 [brltty] file opened: /etc/brltty/Text/ltr-alias.tti 
fd=10
2016-12-13@09:44:11.382 [brltty] including data file: 
/etc/brltty/Text/ltr-alias.tti
2016-12-13@09:44:11.389 [brltty] file opened: /etc/brltty/Text/ctl-latin.tti 
fd=9
2016-12-13@09:44:11.390 [brltty] including data file: 
/etc/brltty/Text/ctl-latin.tti
2016-12-13@09:44:11.398 [brltty] file opened: /etc/brltty/Text/num-dot6.tti fd=9
2016-12-13@09:44:11.398 [brltty] including data file: 
/etc/brltty/Text/num-dot6.tti
2016-12-13@09:44:11.398 [brltty] file opened: /etc/brltty/Text/num-alias.tti 
fd=10
2016-12-13@09:44:11.398 [brltty] including data file: 
/etc/brltty/Text/num-alias.tti
2016-12-13@09:44:11.400 [brltty] file opened: /etc/brltty/Text/common.tti fd=9
2016-12-13@09:44:11.400 [brltty] including data file: 
/etc/brltty/Text/common.tti
2016-12-13@09:44:11.401 [brltty] file opened: /etc/brltty/Text/spaces.tti fd=10
2016-12-13@09:44:11.401 [brltty] including data file: 
/etc/brltty/Text/spaces.tti
2016-12-13@09:44:11.415 [brltty] file opened: /etc/brltty/Text/boxes.tti fd=10
2016-12-13@09:44:11.415 [brltty] including data file: /etc/brltty/Text/boxes.tti
2016-12-13@09:44:11.417 [brltty] file opened: /etc/brltty/Text/blocks.tti fd=10
2016-12-13@09:44:11.417 [brltty] including data file: 
/etc/brltty/Text/blocks.tti
2016-12-13@09:44:11.417 [brltty] Texttabelle: de
2016-12-13@09:44:11.417 [brltty] program exit event added: text-table
2016-12-13@09:44:11.418 [brltty] Attributtabelle: left_right
2016-12-13@09:44:11.418 [brltty] program exit event added: