eSpeak and Say All running sentences together in NVDA 2023.3

[tech10]

Since upgrading to NVDA 2023.3, I've noticed that Say All is running sentences together with eSpeak, most notably, the end of one paragraph and the sentence at the beginning of another. This doesn't occur immediately, but two paragraphs down or so, which makes listening to long segments of text a bit awkward.

Steps to reproduce:

Use NVDA with the eSpeak synthesizer. Check the rate boost checkbox and put the slider at 40 percent, minimum. Begin reading a section of text in a browser or document that's at least five or six paragraphs long, make sure you know where the sentences end on the paragraphs and what the punctuation is. You should notice that the sentences at the end of one paragraph and at the beginning of the next run together, as though in a single sentence.

Actual behavior:

eSpeak will run together the sentence at the end of one paragraph to the beginning of the sentence in the next, at least two or three paragraphs down, as though the sentences are a single sentence.

Expected behavior:

eSpeak should read each sentence with appropriate pauses for punctuation, just as it does while reading multiple sentences in a single line, without using say all.

NVDA logs, crash dumps and other attachments:

I have no logs to insert here. I did view the speech viewer, which had all punctuation appropriately included, so that side of things doesn't appear to miss anything. I also used Windows OneCore voices, which read things correctly, with appropriate pauses for punctuation.

System configuration

NVDA installed/portable/running from source:

Installed.

NVDA version:

2023.3

Windows version:

Windows 11, 22H2

Name and version of other software in use when reproducing the issue:

Google Chrome, version 118.x. Notepad, or any other simple multi-line edit field.

Other information about your system:

Other questions

Does the issue still occur after restarting your computer?

Yes.

Have you tried any other versions of NVDA? If so, please report their behaviors.

NVDA versions before 2023.3 do not reproduce this issue.

If NVDA add-ons are disabled, is your problem still occurring?

Yes.

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

Yes.

[Brian1Gaff]

This sort of thing happens in PDF files a lot. I thought it was due to some non standard spaces being used that the synth ignores. Brian

…

-- ***@***.*** Sent via blueyonder.(Virgin media) Please address personal E-mail to:- ***@***.***, putting 'Brian Gaff' in the display name field.

[lukaszgo1]

This issue is reproducible for me on NVDA alpha-29844,f14d344f, however only with WASAPI enabled which is the default. @tech10 Would you be able to disable WASAPI in advanced settings, and confirm the problme does not occur for you in that case? cc @jcsteh for awareness.

[tech10]

Disabling WASAPI does stop this issue from occuring for me, so it does seem to be related somehow to the implementation of WASAPI, at least, while eSpeak is using it.

Another way to detect if this issue will occur is, at the noted rate values I posted above, spell a line of text. If this issue will occur, the pauses between letters in a spelled line will decrease until each letter is run together without any pauses between them. With WASAPI enabled as is the default, this occured for me, but with it disabled, each letter had an equal pause from all other subsequent letters without an accelerating decrease of pauses between the letters. And, paragraphs didn't run one sentence into the other, either.

[jcsteh]

Urgh. I'm seriously starting to regret implementing WASAPI support. :)

[jcsteh]

What's interesting about this is that the WASAPI code definitely isn't eliminating any pauses. My guess is that the pauses you hear between paragraphs during say all and letters when spelling aren't actually pauses generated by eSpeak, but rather, they are pauses caused by the time between when NVDA gets notified that eSpeak has finished speaking and the time that NVDA sends the next utterance. What's probably happening is that the WASAPI code is notifying too early when there are multiple consecutive utterances.

What this does mean is that if we ever send consecutive utterances ahead of time (which might make things a bit snappier for slower synths), we're going to hit this problem consistently. But I guess that's a problem for another day.