search

nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
https://www.nvaccess.org/
Other
2.1k stars 634 forks source link

NVDA's late response speech in letter navigation #10971

Closed SeanTolstoyevski closed 1 year ago

SeanTolstoyevski commented 4 years ago

Hello, I have been following NVDA's transition to python3 for a long time. Meanwhile, I encountered a problem. I do not know what kind of analysis I will present on this topic. But with the same settings, NVDA 2019.2 reacts faster. When I move around the screen by pressing any letter, NVDA waits too long to speak. I think there is an estimated 200 ms delay.

Steps to reproduce:

For example, let's imagine that we are navigating on the desktop

  1. Windows+M = Folder View, or another folder

Our sample items are:

Actual behavior:

  1. Let's navigate between the items here by pressing the first letters of the items. Example: press g: google chrome, after press: github desktop

Result: Compared to the python 2 version of NVDA, 2019.3 seems to have a late response in letter navigation.

Expected behavior:

System configuration

NVDA installed/portable/running from source:

NVDA version:

Problem: 2019.3

Windows version:

windows 1903, 64bit, 18358.1

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

IBMTTS: IBMTTS driver; Status: Enabled; Version: 19.8B4; Author: David CM dhf360@gmail.com and others I tested it with other synthesizers. No problem is accuring.

Other information about your system:

There is an SSD. No problem from CPU, RAM and SSD.

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.

2019.2: non-problem. speed response

If addons are disabled, is your problem still occuring?

yes

Did you try to run the COM registry fixing tool in NVDA menu / tools?

yes

Notes!

There may be places I am confused about English. My main language is not English. Please pay attention to plain writing when answering me. Sometimes I can't understand you. Because technical problem.

I can write other information if you want. Maybe there may be something I forgot.

And this problem is very frustrating. I hope we can find a way to fix it.

jcsteh commented 4 years ago

I did play with an immediate requestPump for other reasons. At present, a Unfortunately, even a timer with the time set to 0 (i.e. setting core.PUMP_MAX_DELAY to 0) takes ~15 ms to run. That means the pump would have to be able to run outside of a timer when necessary, which makes things complicated because of re-entrance and the like.

SeanTolstoyevski commented 4 years ago

When the changes indicated by @jcsteh's diff are made, the delay decrease from 70 ms to 51 ms.

We still have 20 ms, which is too much.

some of my friends don't use github. That's why they can't write their opinion here. When they try new versions of NVDA, they go back to the old version.

I hope you can figure it out. For me, the speech manager and synthesizers are complex enough.

Qchristensen commented 4 years ago

Having tested this for another user, am I correct in reading this issue as being when you use first letter navigation on the desktop (or in File Explorer, etc), the issue is that with speak typed characters on, NVDA reads, for instance, "R Recycle Bin, 1 of 10" - where there is a large delay between (in this case) reading "R" and "Recycle bin...".

If you turn speak typed characters off (NVDA+2), there is no delay and NVDA immediately reads "Recycle bin, 1 of 10" in this case.

One workaround for users in the meantime, might be to create a configuration profile for the desktop / file explorer, in which speak typed characters is off.

I found there is no delay with eSpeak, some delay with OneCore and a big delay with SAPI5. If Speak command keys is enabled, the delay is the same when navigating around the desktop with the arrow keys as it is when using first letter navigation.

akash07k commented 4 years ago

@Qchristensen Yes, Even I too face this delay on regular basis.. Due to this, I'm forced to keep speak typed characters off in file explorer.

Having tested this for another user, am I correct in reading this issue as being when you use first letter navigation on the desktop (or in File Explorer, etc), the issue is that with speak typed characters on, NVDA reads, for instance, "R Recycle Bin, 1 of 10" - where there is a large delay between (in this case) reading "R" and "Recycle bin...".

If you turn speak typed characters off (NVDA+2), there is no delay and NVDA immediately reads "Recycle bin, 1 of 10" in this case.

One workaround for users in the meantime, might be to create a configuration profile for the desktop / file explorer, in which speak typed characters is off.

I found there is no delay with eSpeak, some delay with OneCore and a big delay with SAPI5. If Speak command keys is enabled, the delay is the same when navigating around the desktop with the arrow keys as it is when using first letter navigation.

SeanTolstoyevski commented 4 years ago

hi @Qchristensen

Having tested this for another user, am I correct in reading this issue as being when you use first letter navigation on the desktop (or in File Explorer, etc), the issue is that with speak typed characters on, NVDA reads, for instance, "R Recycle Bin, 1 of 10" - where there is a large delay between (in this case) reading "R" and "Recycle bin...".

Yes, this is what I want to tell. now this is 70 ms.

and I use it by creating a profile.

SeanTolstoyevski commented 3 years ago

average delay 0.54 ms in latest master branch

It seems to have decreased from 0.70.

its still a lot of delay compared to 2019.3, but I wanted to report the improvement.

feerrenrut commented 3 years ago

average delay 0.54 ms in latest master branch

@SeanTolstoyevski I assume you mean 54ms?

If this delay is something that you are acutely aware of in daily usage without measuring it, then I doubt this is an accurate measurement of the experience. This is a very nuanced topic, but I expect comparing an average of 50ms to 30ms, a difference of 20ms to be bordering on imperceptible:

I only mention this because I want to be clear about what this experience actually entails. NVDA has the time since input measurement, this is useful for NVDA developers to see if newly introduced code has significantly affected performance. However, it does not account for the time that Python might take when calling to an external speech synthesizer DLL or swap to another thread for the synthesizer. This could have changed in Python, and is quite likely out of our control. Thus, it could be that the experienced lag between input and audio output is much greater than what is being measured here. If this is so, then we can use the difference in lag as evidence as where we should look.

jcsteh commented 1 year ago

The reason for the change here between 2019.2 and 2019.3 is likely that 2019.3 and later (specifically, speech refactor) waits for one utterance to complete before pushing the next utterance. For synths which incur a significant delay at the beginning or end of an utterance, I guess this could be problematic. This change was made to support new behaviour like resuming speech after it is interrupted by higher priority speech such as an alert, automatic synth/voice switching, etc. However, I wonder whether it'd be possible to queue multiple utterances ahead of time in the case where the next utterance doesn't require a voice switch, changing priority, etc.

Adriani90 commented 1 year ago

@SeanTolstoyevski could you please test with NVDA 2023.2 and report how it is working now? I notice a much better performance, though still some minimal difference between eSpeak and Onecore voices.

SeanTolstoyevski commented 1 year ago

Hello @Adriani90 ,

What options do I need to activate in the debuggin settings to see the delay times?

Adriani90 commented 1 year ago

You have to enable time since input in the debugging list in the advanced settings. Then you see the differences between key press and speech in your log file in Seconds.

SeanTolstoyevski commented 1 year ago

Thanks @Adriani90 .

When I examine it, there is a clear improvement. I think this is old and normal. You can close this.

Thanks to everyone working on this issue.

Adriani90 commented 1 year ago

Thanks for testing, yeah such issues are really hard to investigate and I am glad a solution could be found. Closing as works for me.