NVDA-IBMTTS-Driver
NVDA-IBMTTS-Driver copied to clipboard
eci.dll is not working with 64-bit versions of nvda.
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.
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.
@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.
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.
@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?
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.
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!
I also am working on this.
@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.
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
I'm looking forward to this
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
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
hello, anything that can be tested as of yet?
@davidacm
que tal amigo, has podido lograr algún avance, estaría excelente probar el prototipo que creaste.
I took a stab at this, for threshold eloquence. However, say all doesn't work, and I don't know why. https://github.com/fastfinge/eloquence_64/
I took a stab at this, for threshold eloquence. However, say all doesn't work, and I don't know why. https://github.com/fastfinge/eloquence_64/
i am checking this, maybe i can make it work?
hmm, after patching it i can't seem to be able to make it work. it gives me this. ERROR - synthDriverHandler.getSynthList (13:42:48.871) - MainThread (14236):
Error while importing SynthDriver eloquence
Traceback (most recent call last):
File "synthDriverHandler.pyc", line 451, in getSynthList
File "synthDriverHandler.pyc", line 438, in getSynthDriver
File "importlib_init.pyc", line 88, in import_module
File "
Fixed. Forgot a subdirectory in the build script. Sorry! Classic "It works on my machine".
hello, the addon loded fine, however i can't seem to make it speak. doesn't show anything useful in the log either.
What does eloquence-host.log in the NVDA addon folder show? Also, we should probably move into the repo I created for this work so as not to spam this issue.
What does eloquence-host.log in the NVDA addon folder show? Also, we should probably move into the repo I created for this work so as not to spam this issue.
i was thinking the same thing, however your issues tab doesn't show up there here is the log. eloquence-host.log
Enabled issues on the repo. And made a new PR that fixes it? Maybe? I'm baffled; it's working on both my machines.
Enabled issues on the repo. And made a new PR that fixes it? Maybe? I'm baffled; it's working on both my machines.
i just tested and it still doesn't work. i have made an issue on your repo
@aryanchoudharypro
I just tried @fastfinge's project and it does work, but when I switch windows it crashes, and as @fastfinge says, it doesn't read absolutely everything.
This happens regularly due to some kind of filter or buffer issue.
By the way, what is the base file for this project, that is, the file in charge of reading and latency? I'd be interested in knowing so I can work on it.
I installed Python 3.13.0, 32-bit. I assume that's the correct version, right?
The project looks promising, it has a fairly low latency, but it has similar errors that I was solving some time ago with a 64-bit proxy for Eloquence of SAPI 5. Only this project has too many files and I don't know which one is in charge of latency and reading.
Correct. The project is laid out like this:
- host_eloquence32.py: runs in its own 32-bit python process, loads eci.dll, and receives commands from NVDA and sends back audio.
- _eloquence.py: communicates with host_eloquence32.py, runs inside 64-bit Python.
- eloquence.py: is responsible for exposing Eloquence to NVDA as a synth driver
- _multiprocessing.pyd: Is the 32-bit version of the multiprocessing Python module. It is required by host_eloquence32.py.
- _multiprocessing64.pyd: Is the 64-bit version of the multiprocessing module, required by _eloquence.py, as NVDA does not include the multiprocessing module in its version of Python
- build.py: responsible for building the actual addon
- build.cmd: compiles the 32-bit host_eloquence32.py into a standalone executable, then runs build.py.
@fastfinge
Hi! I've fixed several bugs you had, and I think it will be usable soon.
For now, the process doesn't crash so easily.
The only thing missing is the bug you mentioned earlier.
For now, the synthesizer can be used.
https://www.dropbox.com/scl/fi/epryt3qcta4idwebz9hop/eloquence_64-master.zip?rlkey=q4spx3641zegpkcj55lhvt5o5&st=wiacc67m&dl=1
@fastfinge
@aryanchoudharypro
I'll be waiting for your response. I hope this version I just released works for you.
At least for me, it's already usable.
@fastfinge I've been using the version I fixed for an hour or two and haven't encountered any errors while running it, except for the one you mentioned, so it's practically usable. I've even browsed several sites and performed various tasks.
Thanks, excellent work! I have merged your code, and also fixed say all. However, when using say all on the web, the audio can become choppy. But this otherwise works. I will do a release shortly.