MakeVoice installed automation voice not detected by NVDA

[mzgoddard]

Testing with a Windows 11 Image installing the voice with MakeVoice, the speech voice is not detected by NVDA. Narrator does detect the voice. As of d71855c installing with the install js script, NVDA detects the voice.

Guest OS: Windows 11
VM Image: 2023 Dev Image
NVDA Version: 2023.1
Host OS: macos 13
VM Software: Parallels Desktop 18

[mzgoddard]

I'm not sure if its related but while NVDA detects and can select the automation, a simple server does not receive any speech events. Narrator does can both selection the voice and speech events are received from this.

simple server

const net = require('net')
const server = net.createServer(s => {console.log('connection'); s.on('data', (...args) => console.log('event', args));})
server.listen('\\\\.\\pipe\\my_pipe', (e) => e ? console.error('error', e) : console.log('listening')), 0

[jugglinmike]

@mzgoddard Is there any chance you're using the "x64" build target in Microsoft Visual Studio rather than the one named "Win32"? The two screen readers appear to differ in the architecture of the voices they will load: if I build for x64, then I see what you've reported (Narrator lists the voice and NVDA does not). If I build for Win32, I see the opposite (NVDA lists the voice and Narrator does not).

[mzgoddard]

Oh. Yes I think that is what I've been building under. I was building with Visual Studios 2022 and I think it was defaulting to building the x64 build and was putting the build artifacts in a x64\\Debug or x64\\Release directory. (I did try Debug and Release to see if that affected it.)

[jugglinmike]

Okay, cool. I think the short-term fix is to document this requirement since Visual Studio clearly doesn't behave the same way on all systems (despite writing the build configuration to a comment in one of the checked-in C++ files--it apparently doesn't read from that file).

I'm reluctant to remove the x64 build target altogether, though. We may need it in the future (e.g. when we add support for Narrator), and I'm somewhat uncomfortable even temporarily removing code that's been generated by a foreign (to me) build system.

Ideally, we could just build for both architectures every time, but I'm not sure that's feasible. Just thinking aloud here:

• Can the Windows registry support two versions simultaneously? Or would we need to assign distinct names to each version so they could coexist?
• Can Visual Studio be configured to do either of those things?

What do you think, @mzgoddard?

[mzgoddard]

I'm also reluctant to remove the x64 build. At some point, maybe sooner than later, we probably need to add an arm build. I know windows has a x64 emulator of some kind but I don't know if or how that may work for DLLs like we build here.

I figure since we run regsrv for 32 and 64 bit on 64bit systems we can probably get both working without naming them separately. The Registry refers to a GUID that is used for both 32 and 64. So I'm guessing the system distinguishes 32 and 64 under the same GUID. Maybe there is a error we're not detecting or propragating when registering for 32 with a x64 build?

[jugglinmike]

That's a far more informed theory than I've been able to come up with! It also sounds like a great starting point for when we start working on the long-term fix.