Proposal: eloquence HQ

[hozosch]

It's not something I'm asking you to implement yourself, but rather something I've been working on with the help of AI (gemini and ChatGPT). I'd like to hear your opinion first on whether you think it's worth integrating or not, before creating a pull request. It's an upsampling algorithm with a smooth filter which produces a clearer sounding eloquence, but without the harsh artefacts of simple upsampling. Instead of writing it in pure Python, I wrote the algorithm in c as an external library (dll) and called it with ctypes on the Python side for best performance. The result is a voice which has clearer s sounds while still being smooth. I used 44 KHz instead of 22, because it makes filtering easier. The input itself still consists of the 11 KHz signal, it's my external upsampling which does the trick.
And don't worry, although practically everything was coded using AI, it's been verified and tested by me, and it's working exactly as it should. There are no glitches.
I think the best way is to introduce the sample rate combo box we have in the IBMTTS driver, and instead of the 22 KHz signal, include my smooth 44 KHz option. If we do it like this, it would be great if you could port the sample rate setting over, and then once that's done, I can send you my upsampling code. What do you think?

[hozosch]

I should also note that based on the numbers I see in Task Manager, CPU usage does not appear to increase. The latency also seems unchanged compared to the original driver.

[titet11]

@hozosch

The suggestion sounds pretty good, but I'd prefer you work on optimization, latency, and resource usage, as well as avoiding race conditions.

[hozosch]

Thanks for your feedback.
I actually tested the same algorithm in the IBMTTS driver for NVDA as well. It first started with a pure Python implementation, and in the 32 Bit NVDA and the IBMTTS driver, it was noticeably slower, but after moving the processing to a small C DLL and calling it via ctypes, the performance became essentially identical to the original signal processing in both 32-bit and 64-bit builds.
CPU usage appears negligible in practice in my tests.

[hozosch]

Regarding race conditions, they could theoretically happen, but NVDA only ever runs a single audio worker thread. I did try TLS at first, but it caused 64-bit NVDA to fail loading the DLL, and stronger clicking noises in the 32 bit IBMTTS driver, so it’s not really an option. So far, I haven’t seen any issues from this, so the problem is negligible in practice.

[fastfinge]

My advice would be go ahead and create a fork. That way we can all test.Sent from my iPhoneOn Mar 15, 2026, at 11:44 AM, hozosch ***@***.***> wrote:hozosch left a comment (fastfinge/eloquence_64#88) Regarding race conditions, they could theoretically happen, but NVDA only ever runs a single audio worker thread. I did try TLS at first, but it caused 64-bit NVDA to fail loading the DLL, and stronger clicking noises in the 32 bit IBMTTS driver, so it’s not really an option. So far, I haven’t seen any issues from this, so the problem is negligible in practice. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[hozosch]

Right on! I already created one to submit my improved German translation, which you have merged already, so I will do the upsampling in that one too. But as of now, it's only using my upsampled signal, and there's no way to change it. I would like to have it changeable like in IBMTTS. What would you suggest, shall I submit it as is, or add the sample rate setting first?

[titet11]

@hozosch

It would be better if you added the sampling configuration. As for the other thing, have you tried replicating the logic of ibmtts? Sometimes it works, sometimes it doesn't.

[hozosch]

Ok, I will see about getting the configuration added then. Regarding the other thing, do you mean race conditions? AS I said, I really don't see why we should worry about them in this case. As I seem to understand it, if they happened, they would show themselves really badly, but what I'm getting instead is a really snappy and smooth output. Also keep in mind that NVDA only runs a single audio worker thread. The upsampler is integrated in IBMTTS as well, and it's equally smooth there.

[titet11]

@hozosch

Great. I'll be waiting for your request on Jithub to run the tests.

[amirsol81]

@hozosch Same here! I'm looking forward to testing it.

[hozosch]

Ok, here I'm having trouble what to do. The implementation is done (configuring the sample rate from settings works correctly), but I did my changes based on the stable version, which has some changes compared to the master branch. So, obviously, there are conflicts now. Ah well, I'll see what I can do.

[amirsol81]

@hozosch Interesting development IMO! I'm curious to see how 44kHZ sounds in action. It would also be quite interesting to see how 44kHZ handles the Community Dictionaries.

[hozosch]

All right, it's finally fully done and up on my fork! Go ahead and test it!

[hozosch]

By the way, the upsampler.dll is build using MinGW64, or 32 if you wanted to include it in IBMTTS.

[amirsol81]

@hozosch Thanks! Could you please provide a download link? I mean how can I grab it from your fork in the form of an installable add-on?