eci.dll is not working with 64-bit versions of nvda.

[titet11]

Hi, is there any way to fix this problem?
NVDA just released the first 64-bit versions, and since eci.dll isn't working, I feel pretty sad. I feel like something's missing, and honestly, nothing's the same without eloquence. I didn't expect this to happen, and I'm very sad.

[fastfinge]

NVDA was going to create a way to load old synth drivers into the 64-bit NVDA. But I'm not seeing any information about this in the developer's guide.

[titet11]

@fastfinge

Probably not.

My question is: would it be difficult to implement this from this driver? Based on my testing, 32-bit synthesizers don't work in 64-bit. For example, SAPI 5 doesn't recognize 32-bit Eloquence.

[fastfinge]

The solution is creating a 32-bit process to load the DLL, then using RPC to shuttle data between the processes. It will, however, introduce a lot of lag.

[titet11]

@fastfinge

Do you think that if NVDA implements a solution to support older drivers, the latency will be completely eliminated? Or will this problem persist?

[davidacm]

Sorry, I was not aware about the new alpha of 64 bits.
I have an idea to develop this implementation.
Basically, I'm thinking of building a small intermediate library that acts as a bridge between the 32-bit and 64-bit processes, using shared memory. This way, the audio buffer wouldn't need to be copied between processes; it should be way smoother than using RPC or something like a local TCP server.
That said, even in the worst case, like copying the audio stream over a network-style protocol, it probably wouldn't be a big deal thanks to how powerful modern CPUs are.
I've seen some pretty inefficient implementations in certain TTS systems, and the latency is still fine.
Of course, I'd rather make it as efficient as possible, but if I can't get the shared memory solution working between 32 and 64 bits, I'll just go with one of the more standard, proven methods.

I was working on the accurate indexes for IBMTTS, that is working fine, but with some lag sometimes... So I will change the priorities and work on this implementation for 64 bits copatibility.

[amirsol81]

Sorry, I was not aware about the new alpha of 64 bits. I have an idea to develop this implementation. Basically, I'm thinking of building a small intermediate library that acts as a bridge between the 32-bit and 64-bit processes, using shared memory. This way, the audio buffer wouldn't need to be copied between processes; it should be way smoother than using RPC or something like a local TCP server. That said, even in the worst case, like copying the audio stream over a network-style protocol, it probably wouldn't be a big deal thanks to how powerful modern CPUs are. I've seen some pretty inefficient implementations in certain TTS systems, and the latency is still fine. Of course, I'd rather make it as efficient as possible, but if I can't get the shared memory solution working between 32 and 64 bits, I'll just go with one of the more standard, proven methods.

I was working on the accurate indexes for IBMTTS, that is working fine, but with some lag sometimes... So I will change the priorities and work on this implementation for 64 bits copatibility.

@davidacm That would be much appreciated!

[Elshara]

I also am working on this.

[titet11]

@Elshara

It would be great to hear your progress. I hope you can comment on it here, or if you like, you can upload it to JitHub.

[davidacm]

Hi @Elshara, could you tell us what is your approach to communicate between 32 and 64 bits? Are you using something like sockets or pipelines, or are you sharing memory like I mentioned before?
Perhaps we could benefit from our ideas.

I started working on this yesterday, using rust as the language for the required processes.
But I could use c++ if were needed.
My current state is, doing small tests from a 64 bit process. For now, I was able to compile and communicate from nvda 64 to 32 bits dll, and was able to make IBMTTS to speak something using the speak function and the own IBMTTS audio output.
The next step is to get the audio buffer shared between the eci library and the ibmeci driver.
All those tests are not in real time, I will work on that once I manage to share and synchronize the audio buffer (without copying memory or so) because I don't want to use sockets.

I guess I will push a new branch once I get some basic results.

best regards,
David

[aryanchoudharypro]

I'm looking forward to this

[aryanchoudharypro]

i think nvAccess mite have legal obligations that prevent them from addressing anything related to IBM tts or other drivers. they already said that they will make a ipc aplication to support older sinths / brale displayes, but i am not sure as to when that is going to happen