mastodon - Link to source
I spent several hours over the last few days implementing WASAPI audio output for NVDA for some reason. As I suspected, I don't think it's really any more responsive, but I'm hoping it might eventually fix some tricky bugs with the old WinMM implementation, though it'll probably introduce a bunch of its own. Still quite some way to go before it's fully featured; e.g. it doesn't support any device other than the default yet, nor can it recover if a device disappears. #NVDASR
#nvdasr

Peter Vágner reshared this.

in reply to Jamie Teh

mastodon - Link to source

Jamie Teh

I'm also providing an option to allow NVDA synth drivers to pass raw memory pointers for audio data instead of converting to a Python bytes object, which is a lot of unnecessary memory copying and overhead when the ultimate audio buffer is just raw memory (no Python objects) anyway. I've updated eSpeak and OneCore already and it works quite nicely, though I don't really notice a difference on my system.
in reply to Leonard de Ruijter

mastodon - Link to source

Jamie Teh

@leonardder Currently, it's API breaking for synths which choose to use it in that they won't work with the old nvwave. Synths using the old method will still work with the new nvwave though. However, I realised there's a way to implement the raw pointer thing with the old nvwave. It can just convert to a Python bytes buffer on the fly.
@Leonard de Ruijter
⇧