Conversation
…ons in NVDA asynchronisly. This works around a bug in RPYC (RPYC issue #345) where if making a remote call on one thread and then another on a second thread, the second may eat the return of the first causing it to time out. Plus we don't need the return or need to wait anyway.
Contributor
There was a problem hiding this comment.
Pull request overview
This pull request fixes an occasional freeze that could occur when using 32-bit SAPI synthesizers (introduced in PR #19432). The freeze happened when speech was cancelled at the same time a speech utterance was finishing, causing NVDA to hang in the synth.cancel call.
Changes:
- Modified notification callbacks in the synthDriver service to be asynchronous, preventing the synthDriver process from blocking while waiting for callback returns
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
seanbudd
approved these changes
Feb 13, 2026
7 tasks
seanbudd
pushed a commit
that referenced
this pull request
May 25, 2026
…026.2 as it is not stable enough yet. (#20206) Fixes #19667 Fixes #19819 Reverts #19672 Summary of the issue: Experimental code was recently added to NVDA (after 2026.1) that caused the 32 bit synthDriver shim to send its audio back to NvDA for playing, rather than playing it directly in its own process. This was done to test / prepare for the time when add-ons would be running in an app container, and therefore probably would not have direct access to the audio device. However, currently this code is still quite unstable, causing NVDA to freeze when rapidly changing the speech rate, or arrowing up and down in lists, when using sapi4 or 32 bit sapi5. This instability is most likely a similar issue to what was fixed in pr #19609, where RPYC is handoing the return of a call on the wrong thread. But in this case, it is calls to/from nvwave in NVDA's process. Description of user facing changes: Description of developer facing changes: Description of development approach: Simply instruct the synthDriver process not to install the nvwave proxy that brokers back to NvDA. Reverts Re-enable audio ducking for proxied x86 speech synths #19672 so that 32 bit synthDrivers suspend audioDucking while they are running, as audioDucking cnanot be supported without brokering audio.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Link to issue number:
Fixes #19594
Summary of the issue:
With the introduction of 32 bit sapi support in pr #19432, an occasional freeze may be seen when using 32 bit sapi synths. Specifically when cancelling speech at the same time a speech utterance was finishing.
NVDA would freeze in its call to synth.cancel and the synthDriver process would freeze when calling the synthIndexReached or synthDoneSpeaking callbacks.
This seems to be related to RPYC issue #345, where if a remote call is being made on one thread, but another thread is also moving a remote call and or somehow serving or polling the connection, the second thread may accidentally read and eat the return of the call in the first thread, thus causing the call on the first thread to time out.
Description of user facing changes:
Description of developer facing changes:
Description of development approach:
Testing strategy:
Known issues with pull request:
None known.
Code Review Checklist: