Okay. I finally had enough of git pull and the like making my entire system unusable thanks to UIA event flooding that I took the plunge and switched to Windows Terminal with UIA notification events. I was having trouble with Windows Terminal previously, but that was with diffing. Notification events seem to be working fairly well so far. Let's see how it goes.
One concern I do have is that NVDA necessarily registers for notification events globally, which means that a notification event flood from a background terminal is going to impact performance. Hopefully terminal manages notification events better than it does text events. We shall see.
=> More informations about this toot | More toots from jcsteh@aus.social
Well that didn't take long. Spamming the console still makes the system pretty much unusable if the console is focused when it happens. But interestingly, if the spam starts in the background or I can manage to alt+tab out (which is very difficult because it's so slow), it seems to behave. That either means that Terminal is smart enough not to send notification events while in the background (but then I'm not sure why NVDA has explicit code to ignore those) or that the poor performance is entirely due to NVDA struggling to process the notification events (but ignoring them is okay).
=> More informations about this toot | More toots from jcsteh@aus.social
Terminal doesn't fire UIA notification events when in the background, which is great. It turns out that the thing that's really slowing down NVDA's handling of those on my system isn't speech processing or anything like that. It's... logging! I tend to have my log level set to debug, which logs a lot. I never realised just how much that logging could slow things down when there's this much data.
Interestingly, if I set my speech mode to beeps, that's also very laggy. I guess it's expensive to continually generate and play the tone, even if we stop it very quickly.
=> More informations about this toot | More toots from jcsteh@aus.social
@jcsteh Okay, maybe this is a stupid suggestion but…why not pregenerate the required tone for the required duration when NVDA starts? Then you don't have to generate it over and over.
=> More informations about this toot | More toots from jaybird110127@dragonscave.space
@jaybird110127 That is indeed one option I thought of to optimise that, yes. Whether or not that is the actual bottleneck is yet to be determined.
=> More informations about this toot | More toots from jcsteh@aus.social
@jcsteh A year or two ago I actually came up with a weird way to not have to generate tones at all. When speech mode is set to beeps, rather than playing a specific tone, just output the actual text to be spoken, not as speech but in its raw binary form, to the audio device. This would be most useful with long text dumps. For something like single characters, a single byte probably isn't going to convert to enough sound to make a noticeable noise.
=> More informations about this toot | More toots from jaybird110127@dragonscave.space
@jaybird110127 I follow. As you say, though, it's problematic for smaller chunks, which I'd say is fairly common for a screen reader.
=> More informations about this toot | More toots from jcsteh@aus.social
@jcsteh If, by chance, you're sitting there going "Huh? What in the world is this kid talking about?" Start any audio editor that lets you open headerless files as raw PCM. Open a file that is, in fact, not an audio file at all. Specify the sample rate, bit depth, number of channels, etc. as you like. If you then play it, you'll hear some random noise. Text files, logs, etc. tend to generate the coolest noises. Anything compressed is going to sound like white noise, in other words, a loud hiss covering the entire frequency spectrum.
=> More informations about this toot | More toots from jaybird110127@dragonscave.space This content has been proxied by September (3851b).Proxy Information
text/gemini