Open zstanecic opened 3 years ago
Hi,
Note: this issue was brought up on a form I won't name, but to summarize some main points:
Hope this helps. Thanks.
there are lots of possibilities which we are out because of lacking of support of x64 mode. There are lots of AI libraries like torch or onnxruntime which is two times faster on x64 rather than on x86.
I think nvaccess should consider a possibility to if not transit but make it possible for developers to build nvda without a pane. There are all dependencies available for x64.
On 7/10/23, Joseph Lee @.***> wrote:
Hi,
Note: this issue was brought up on a form I won't name, but to summarize some main points:
- We (NVDA developers) need examples please - not just registry keys, but real-life examples of 64-bit SAPI5-based speech synthesizers. Only then we can seriously consider what to do.
- NVDA is a 32-bit application for various reasons, among which is the fact that it is running on top of a 32-bit Python runtime. One way to support x64 only modules is through a bridge (or two if we want to go all out and also support ARM64 only SAPI5 engines/interfaces). This can create performance penalty, albeit quite unnoticeable to users unless it is so severe that requires debugging.
- It is not a simple matter of moving NVDA to become a 64-bit screen reader
- similar to what we have now, bridges must be created to communicate with x86 (32-bit) processes, which is still supported on Windows 11 due to both software and hardware reasons (software thanks to WoW64 and prevalence of 32-bit and/or hybrid 32-bit+64-bit apps and packages; hardware because x64's native execution mode (long mode) supports both 32-bit and 64-bit code). More importantly, we have to think about NVDA's dependencies, with some of them offering both 32-bit and 64-bit Python runtime support (more so for dependencies such as wxPython that ships with DLL's and C extensions (pyd files)); transitioning from 32-bit to 64-bit Python runtime requires early preparation, earlier than Project Threshold a.k.a. Python 2 to 3 transition (NVDA 2019.3) as it will affect more than just NVDA Core.
Hope this helps. Thanks.
-- Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/12805#issuecomment-1627837689 You are receiving this because you are subscribed to this thread.
Message ID: @.***>
-- with best regards Beqa Gozalishvili Tell: +995593454005 Email: @.*** Web: https://gozaltech.org Skype: beqabeqa473 Telegram: https://t.me/gozaltech facebook: https://facebook.com/gozaltech twitter: https://twitter.com/beqabeqa473 Instagram: https://instagram.com/beqa.gozalishvili
Hello there. I recently started testing some neural sounds for developers on my computer. even if they are for developers now, it is not clear what will happen in the near future, maybe they will be available for all users. nvda doesn't have 64 bit sapi 5 support, so I can't test these sounds with nvda at the moment. the new neural sounds are mostly running under 64 bit sapi 5 and I would like to request to add 64 bit sapi 5 support to nvda, or to design a plugin to use 64 bit sapi 5 sounds. it's too bad that you can use these sounds with jaws but not with nvda.
@josephsl I know you've done some thinking about 64-bit contexts for NVDA. Do you have any thoughts on this?
Hi, I think we do need to think about a library (or a bridge really) that will allow NVDA to talk to 64-bit synthesizers and other modules just like we are doing when talking to 64-bit apps via remote helper loader. The reverse will be true (and I think a bit complicated) when it comes time to move NVDA to run on 64-bit Python runtime, but I imagine it won’t happen for a while. Thanks.
Yes, not only synthesizers. Onnxruntime which is used to run onnx models, have 2x performance increase when using x64 library, which very drastic for such things.
On 9/1/23, Joseph Lee @.***> wrote:
Hi, I think we do need to think about a library (or a bridge really) that will allow NVDA to talk to 64-bit synthesizers and other modules just like we are doing when talking to 64-bit apps via remote helper loader. The reverse will be true (and I think a bit complicated) when it comes time to move NVDA to run on 64-bit Python runtime, but I imagine it won’t happen for a while. Thanks.
-- Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/12805#issuecomment-1702570512 You are receiving this because you commented.
Message ID: @.***>
-- with best regards Beqa Gozalishvili Tell: +995593454005 Email: @.*** Web: https://gozaltech.org Skype: beqabeqa473 Telegram: https://t.me/gozaltech facebook: https://facebook.com/gozaltech twitter: https://twitter.com/beqabeqa473 Instagram: https://instagram.com/beqa.gozalishvili
I absolutely agree with that. I think it's time to do some work on this issue. Also, over time, all systems are gradually switching to 64 bit and provide more performance increase.
Hi, moving to 64-bit platforms and runtimes may offer performance improvements, but the fact that operating systems such as Windows continuing to support 32-bit platforms and apps is telling a bigger narrative (well, several): portability across platforms, and in case of a screen reader such as NVDA, access to information for more people across more systems as 32-bit runtime provides more universal appeal for a screen reader as it can run on both 32-bit and 64-bit platforms. But eventually, yes, we need to move to 64-bit platforms, but I don’t see that as a realistic possibility until at least 2026 when I expect enterprises to accelerate adoption of 64-bit mission-critical software (for consumers, Windows 10 is the last operating system to run on 32-bit processors, and for enterprises, they have more time to migrate thanks to Windows 10 Enterprise LTSC). For NVDA, that day will come when Python and/or one or more critical dependencies such as wxWidgets (wxPython) says goodbye to 32-bit platforms, and I expect that to be done in late 2020’s. Thanks.
Why not think to just create the same, bridge for 32-bit apis and give freedom to new technologies.
On 9/1/23, Joseph Lee @.***> wrote:
Hi, moving to 64-bit platforms and runtimes may offer performance improvements, but the fact that operating systems such as Windows continuing to support 32-bit platforms and apps is telling a bigger narrative (well, several): portability across platforms, and in case of a screen reader such as NVDA, access to information for more people across more systems as 32-bit runtime provides more universal appeal for a screen reader as it can run on both 32-bit and 64-bit platforms. But eventually, yes, we need to move to 64-bit platforms, but I don’t see that as a realistic possibility until at least 2026 when I expect enterprises to accelerate adoption of 64-bit mission-critical software (for consumers, Windows 10 is the last operating system to run on 32-bit processors, and for enterprises, they have more time to migrate thanks to Windows 10 Enterprise LTSC). For NVDA, that day will come when Python and/or one or more critical dependencies such as wxWidgets (wxPython) says goodbye to 32-bit platforms, and I expect that to be done in late 2020’s. Thanks.
-- Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/12805#issuecomment-1702670383 You are receiving this because you commented.
Message ID: @.***>
-- with best regards Beqa Gozalishvili Tell: +995593454005 Email: @.*** Web: https://gozaltech.org Skype: beqabeqa473 Telegram: https://t.me/gozaltech facebook: https://facebook.com/gozaltech twitter: https://twitter.com/beqabeqa473 Instagram: https://instagram.com/beqa.gozalishvili
Hi, that’s what I’m proposing, actually – as a compromise for now. Thanks.
NV Access has a couple weeks ago posted a project timeline to migrate NVDA to 64 bit, think this project would resolve this issue https://github.com/nvaccess/nvda/discussions/16304
Hello, this is the perfect thing! so, according to this timeline, when will 64 bit sapi 5 support be added?
according to the idea, it is tentative for 2026.1
Is your feature request related to a problem? Please describe.
My feature request is related to the speech synthesis marked and tendencies when it comes to the various screen readers. For example, jaws for windows and narrator, supports the 64-bit sapi5 interface, while NVDA doesn't support it at all. There are a lot of synths, which are going to support sapi5 only natively via x64 interface, and search the 64-bit registry part to search for the voices in hkey\local_machine\software\microsoft\speech\voices\tokens
Describe the solution you'd like
support sapi 5 x86 and x64
Describe alternatives you've considered
none
Additional context
n/a