User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
Admin
completely blind computer geek, lover of science fiction and fantasy (especially LitRPG). I work in accessibility, but my opinions are my own, not that of my employer. Fandoms: Harry Potter, Discworld, My Little Pony: Friendship is Magic, Buffy, Dead Like Me, Glee, and I'll read fanfic of pretty much anything that crosses over with one of those.
keyoxide: aspe:keyoxide.org:PFAQDLXSBNO7MZRNPUMWWKQ7TQ
Location Ottawa
Birthday 1987-12-20
Pronouns he/him (EN)
xmpp fastfinge@im.interfree.ca
keyoxide aspe:keyoxide.org:PFAQDLXSBNO7MZRNPUMWWKQ7TQ
blog https://stuff.interfree.ca/
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
1mo
@draeand @nick If it wasn't for OpenEVV existing, and making all of this not matter within a year, I would probably write ECI64 in C and have it handle IPC with ECI32 via pipes or something. Then the three different eloquence addons can stop doing IPC, each in a slightly different way, and we can all focus on the actual differences and tradeoffs each one makes. Although, I don't think I can have a shared memory buffer between a 32 bit and a 64 bit process, can I? I still need pipes or something.
1
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
1mo
@draeand @nick Hah. I'm a guy who forgot to clean up a process on close and left it that way for, like, months. I'm far away from doing low level OS work.
2
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
1mo
@draeand @nick No, but you could have ECI64.dll handle all of the IPC stuff, using what ever method you want, behind the scenes in a way that's largely invisible to the 64-bit app. And then every single app that wants to use eloquence doesn't have to do its own IPC.
1
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
1mo
@draeand @matt @nick @miki If I wasn't between jobs, I would. I'll consider it when I have regular employment again.
1
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
1mo
@draeand @nick If we want to rewrite the world, the actually correct way to do this is write ECI64.dll, that's just a shim to call the 32-bit DLL, and then have anything at all that's a 64-bit process and wants to use eloquence load ECI64.dll. The primary reason I haven't done that is lack of talent. Though in hindsight, it probably would have actually been simpler than what I did wind up doing.
1
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
1mo
@nick One of these days I really do need to backport your dictionary handling code. But...that's HAAAARD WORK! wines I don't wanna! The dictionary code as it currently exists makes me sad and afraid.
0
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
1mo
@miki @matt @nick @draeand Well, I can't afford the, like, $400 Microsoft wants for a cert, so...
1
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
1mo
@matt @nick @draeand If you're curious, here's the biggest speedup I could get with half an hours work. I'm not going to even think about releasing this until I've been using it for a few days, though. It needs testing for clicks/underruns introduced by the much smaller audio buffer. github.com/fastfinge/eloquence_64/tree/perf/onedir-and-smaller-buffer
0
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
1mo
@miki @matt @nick @draeand Depends on the security software and the environment and the app. For an unsigned executable in an untrusted environment, running as admin, sometimes it can, yes. Of course this is not usually the case, so that kind of lag isn't going to hit most people, running most apps.
1
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
1mo
@matt @nick @draeand Now that you've got me curious, there are two places I can save. First, building the 32-bit hoast as onedir instead of onefile. Saves 1.5 seconds on first start. Second, I can shorten the audio buffer and save about 40 ms per speech. But that'll need a lot of testing to make sure it doesn't introduce underruns on slow systems.
0
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
1mo
@matt @nick @draeand In the real world, most machines have endpoint security and virus scanning and things that watch IPC carefully, and slow everything down. Especially when you're using TCP. Switching to pipes will probably bring some speedups for some folks, depending.
2
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
1mo
@nick @draeand Just did some quick benchmarking. Based on the hotpath, a rewrite away from python could save as much as, get ready, 0.0005% of processing time.
1
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
1mo
@nick @draeand It is. When the OpenEVV guys fix all the IBM introduced bugs, I intend to switch over to using there dlls, and just build those into the eloquence64 addon and get rid of IPC. Not doing IPC at all will get us a noticeable 40ms or so.
1
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
1mo
@nick @draeand The only other thing it gives you is some disc savings. The 32-bit host does bundle all of Python with it, and unpacks it into a temp directory whenever it runs, then cleans it up when it exits. Well, should clean it up when it exits. It does, now, clean it up when it exits. Sigh.
1
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
1mo
@nick @draeand Yup, I regularly use stuff like unspoken and earcons, so having the sounds line up where they should is really really important to me.
1
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
1mo
@nick @draeand I wouldn't, though. First the dotnet runtime would now be required, and would be a huge memory suck. Second the only lag Python brings is the first startup/JIT compile. Once that happens, it's just reading data off a pipe and passing it to eloquence. Getting rid of TCP saved me somewhere between 40 and 60 nanoseconds. But that's well below the limit of human perceivability. And generating NVDA indexes etc still happens in Python, because that's what NVDA uses. So a low level language just can't save anything here. The reason your rust driver feels more accurate is because you're playing back chunks sooner, and thus making indexing slightly less accurate in return. That's not a tradeoff I'd want to make. If I did, it could just as easily be made in Python.
3
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
1mo
@draeand The ultimate solution is to rewrite the 32-bit eloquence host in something like rust, the way eloquence64RS does. But I don't speak or understand rust, so I'm not confident either writing it myself, or reviewing and sanity checking an AI generated rust host. Plus, NVDA itself, and the addon portion, are in Python. And I prefer to only require contributors (and me) to deal with a single programming language. Based on that round of bug-fixing, I'm already completely incapable of doing an adequate job. More complexity will not help me.
1
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
1mo
@draeand Yes, and that was the problem. Third parties should not have been able to interact with the process that unpickles data. They could because I allowed things to happen as the code took shape over the past six years, and failed to review third partie PR's closely enough, rather than creating an intentional design for it. It then bit me when I forgot to correctly clean up the process that was listening to the TCP socket as part of other changes. The correct answer in this case was to move to named pipes, with process and group ased ACL, not dump pickle.
1
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
1mo
@draeand In my case, I need something fast and built in. It really is the best fit. The issue here was using tcp for ipc. That was a poor decision that just happened rather than being intentionally considered.
1
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
1mo
If you use the eloquence64 addon for the , a critical security release is now available. This is a critical update! Please update as soon as possible.

If you use Eloquence64 on secure screens, after the update, you must IMMEDIATELY! go to NVDA's settings dialogue, select eloquence from the list box, and press the "copy helper to system config" button again.

It fixes the following issues:
* fix: eloquence64 now clears its log file on start
* Fix: in some cases, eloquence64 could write to its log file at 30 megs per second
* fix: in some cases, eloquence64 created multiple temp files and directories that could not be removed
* fix: in some cases, eloquence64 could unexpectedly leave a port open on the computer
* fix: the port and key to communicate with eloquence could be intercepted by other processes running on the machine
* fix: in rare cases, it could have been possible for other processes on the user's machine to cause the addon to load and run arbitrary Python code by causing it to deserialize an attacker supplied pickle. If the addon was running on a secure screen, this would mean instant privilege escalation.
* fixed: crashing or frozen NVDA will no longer leave orphaned eloquence processes behind
* fix: more reliable pause and break lengths
* security hardening: switch to named pipes with DACL for IPC, ensuring no other process can use the 32-bit host

Release page: github.com/fastfinge/eloquence_64/releases/tag/v21

Direct download: github.com/fastfinge/eloquence_64/releases/download/v21/Eloquence-v21.nvda-addon
1
15
4
0