Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fall back to OneCore synth on Windows 10 if a 3rd party synth fails to load #9025

Merged
merged 3 commits into from Dec 8, 2018

Conversation

@michaelDCurran
Copy link
Member

@michaelDCurran michaelDCurran commented Dec 7, 2018

Link to issue number:

Mentioned in pr #8006

Summary of the issue:

If NVDA is configured to load a 3rd party synth and the loading of that synth fails, NVDA then falls back to eSpeak. However on Windows 10, it really should fallback to OneCore, as OneCore is the default synth for NVDA on Windows 10.
This was specifically noticed with the merging of #8006 where if a synth from an incompatible add-on was in use when updating to a 2019.1 pre build, that synth would fail to load due to the add-on being disabled. On Windows 10 this would fallback to eSpeak, but it really should be oneCore.

Description of how this pull request fixes the issue:

In synthDriverHandler there is now a defaultSynthPriorityList which contains the names of all synths (in priority order) that should be tried by default. E.g. oneCore, espeak, silence.
Now if the loading of a synth fails, NVDA will fallback to the next available synth in that list.
For example, if a 3rd party synth fails to load, then on Windows 10, it will go to OneCore. On lower Operating Systems it will go to espeak.
However, if for instance oneCore fails to load, it will try the next thing in the list, which is espeak.

Testing performed:

Set NVDA to a 3rd party synth (NVSpeechPlayer). Disabled the add-on, restarted NVDA, NVDA switched to oneCore.

Known issues with pull request:

None.

Change log entry:

Bug fixes:
If a 3rd party speech synthesizer fails to load, NVDA will fall back to Windows OneCore speech on Windows 10, rather than espeak.

…ore should be tried as one of the default synthesizers to fall back to on Windows 10.
@michaelDCurran michaelDCurran requested a review from leonardder Dec 7, 2018
nextIndex=defaultSynthPriorityList.index(name)+1
except ValueError:
nextIndex=0
if nextIndex<len(defaultSynthPriorityList):
Copy link
Collaborator

@leonardder leonardder Dec 7, 2018

In the very unlikely case that the silence synthesizer does not load, will this create an endless loop? I.e.

  1. OneCore doesn't load, go to espeak
  2. Espeak doesn't load, go to silence
  3. Silence doesn't load, index is 0, go to OneCore

I guess that if nextIndex==len(defaultSynthPriorityList) means that we're stuck with regard to speech. Should we account for this?

@michaelDCurran
Copy link
Member Author

@michaelDCurran michaelDCurran commented Dec 7, 2018

Copy link
Collaborator

@leonardder leonardder left a comment

I don't understand the following: "3. Silence doesn't load, index is 0, go to OneCore". As silence is in the list, and is the last item, nextIndex would be len(defaultSynthPriorityList).

Ah yes, you're right. I missread the code and thought that index would return to 0 instead of len(defaultSynthPriorityList). Go ahead, and sorry for the misunderstanding.

@jage9
Copy link
Contributor

@jage9 jage9 commented Dec 7, 2018

To take this further, should SAPI 5 be in the list after espeak? It's a fringe case, but better to have some speech than none.

@michaelDCurran michaelDCurran merged commit 83b3e83 into master Dec 8, 2018
1 check passed
@nvaccessAuto nvaccessAuto added this to the 2018.4 milestone Dec 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants