User avatar
Pitermach @pitermach@dragonscave.space
6mo
NVDA 64-bit migration breaking older voices, very long (2 posts) The 64-bit NVDA migration is obviously going to mean a lot of older speech synthesizers (such as SAPI4 voices) and braille displays relying on drivers that use 32-bit libraries will stop working. I was really happy to see the issue was being taken so seriously that there were/still are plans to make a compatibility layer, and this was considered a blocking issue, meaning NVDA 2026.1 would not be released without this being addressed. You can read that issue here:
github.com/nvaccess/nvda/issues/19030#issuecomment-3588231868

And then it was "addressed"… By removing any mention of SAPI 4 and other legacy drivers. There are still plans to return to this, and I sincerely hope this happens, as part of work on a different somewhat controversial topic - a new addon environment, with a more restricted API access which will be running in a separate process.

Now, anyone who’s already using Espeak or Microsoft voices with a modern braille display is probably going to just shrug, but this change is going to have some very serious implications that I suspect may cause some people to skip these newer NVDA releases. From my comment on the GitHub issue:
Many people still rely on older speech synthesizers for various reasons. There are languages where the only good speech options are older legacy synthesizers, and many people who use specific voices due to a hearing impairment, because they are more intelligible. For these people using Espeak, OneCore or purchasing a commercial speech addon may simply not be an option.

The only way out will be for addon developers to come up with their own bridging solutions, assuming an addon for the synthesizer is even still being supported. Eloquence already has at least 1 project to do this, and I’d be really curious to hear from people who use it if performance is worse as a result, whether the supposed performance gains are lost due to using a bridged synthesizer. It’s possible to make a fast screen reader with bridged synths — Take ZDSR, which is a 64-bit app but with support for SAPI 4 and 32-bit voices, and it’s blazing fast, faster than NVDA. But no amount of bridged addons will help anyone using a SAPI 4 voice which currently doesn’t have an addon. I’m lucky enough that for Polish, an amazing community sprung up around RHVoice, an open-source synthesizer that now has a number of fast and intelligible voices, but other languages are not so lucky. (1/2)
4
7
0
0
User avatar
Pitermach @pitermach@dragonscave.space
6mo
NVDA 64-bit migration breaking older voices, very long (2 posts) So, at the end of all this I’m personally unsure if the 64-bit transition was necessary or worth all the collateral damage - are there any libraries that NVDA depends on which are now 64-bit only that forced this? If you know I’d love to know as well! ☺️ But at the end of all this, I feel a decision like this should have been consulted with users, instead of just doing the upgrade because it’s the more modern thing. They could have ran a survey to see how many people would be disproportionally affected - there are plenty of international NVDA communities where it could have been circulated. At the end of all this I just hope we don’t lose too many developers, addons, and especially voices in less popular languages from this. For me, I’m probably going to hold off from upgrading for a while. It’ll be like the 2019.2 days pre speech refactor. Here’s hoping things will work out like they did then while also keeping NVDA as performant as it is. (2/2)
1
3
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
6mo
NVDA 64-bit migration breaking older voices, very long (2 posts) @pitermach Python itself intends to drop 32 bit support in the foreseeable future. I think they should have offered two releases in 2026 and pulled the switch in 2027. But either way the transition is not optional. It has to happen in the next couple years. And I use eloquence64 as my daily driver. It’s fine for the most part. The main limitations are NVDA and windows ones. For example my bridge is unsigned so it can’t run on secure screens. And for the record it’s based on threshold. 99 percent of the code is human written, and the other one percent has been reviewed and debugged by multiple humans. I didn’t just shit out an AI conversion and call it a day.
1
1
1
0

User avatar
Pitermach @pitermach@dragonscave.space
6mo
NVDA 64-bit migration breaking older voices, very long (2 posts) @fastfinge Good to know, I'll edit the post slightly, and I appreciate that you and other people put in the effort. Yeah I agree the transition should have been more graceful. Foobar did it this way for example.
0
0
1
0