FlexASIO
FlexASIO copied to clipboard
Improve WASAPI Shared latency
Hello, I see a lot of improvements since our discussions/beta testing from one year ago, congratulations Etienne! I'll update my blog article soon (I shared your project on it, you might remember).
Here I share my current latency results when using FlexASIO 1.5 + Windows 7 x64 + Ableton Live 10 + Lenovo Laptop's built in soundcard (Conexant 20672), here is what I now get:
-
Configuration 1:
backend = "Windows WASAPI" bufferSizeSamples = 128 [input] suggestedLatencySeconds = 0.0 device = "" [output] suggestedLatencySeconds = 0.0 wasapiExclusiveMode = true
Really impressive. I think the 3.63ms latency is not far from reality, we can feel immediate response when playing.
Of course, sincewasapiExclusiveMode = true, no other software can use the soundcard at the same time (like ASIO4ALL), i.e. it's not multiclient. -
Configuration 2: idem with
[output] wasapiExclusiveMode = false
No matter the
bufferSizeSamples(64, 128, 256, 512, etc.), whenwasapiExclusiveMode = false, the reported latency is always > 20ms.
Question @dechamps: do you think there is a hope having < 20 ms with wasapiExclusiveMode = false (I would like to be able to use another software at the same time and have a low latency)?
Is there some room for improvements in non exclusive mode? where in the code could we look further (I can audit precisely if needed)?
20 ms is the buffer size that the Windows audio engine uses, so that's what you get when you use shared mode (which goes through the Windows audio engine).
In Windows 10 Microsoft improved WASAPI by adding ways to achieve lower latencies in shared mode. Assuming that actually works on real systems with real drivers, that would solve your problem. However, I took a quick look at the PortAudio code and, sadly, it doesn't seem to support that extended interface. Someone would need to add that support, and I'm afraid I have no plans to do that anytime soon.
20 ms is the buffer size that the Windows audio engine uses, Oh, good to know! Is this documented somewhere? (if you have a link maybe?)
so that's what you get when you use shared mode (which goes through the Windows audio engine) Do you think this global Windows WASAPI parameter can be modified in regedit.exe or somewhere else? Or would 20ms be hardcoded in WASAPI's source code?
In Windows 10 Microsoft improved WASAPI by adding ways to achieve lower latencies in shared mode. Assuming that actually works on real systems with real drivers, that would solve your problem. However, I took a quick look at the PortAudio code and, sadly, it doesn't seem to support that extended interface. Is might already be on PortAudio project's todo list. If not, we could maybe post an issue there (maybe you have already mentioned this on their forum, if not I can do it?)
See you
Ideas summary:
-
keyboard shortcut to switch between
wasapiExclusiveMode=trueandfalse(#56) -
detect when the DAW (e.g. Ableton live) window loses the focus. When it loses the focus, this means we're probably using another software, let's switch
wasapiExclusiveModetofalse. Back totruewhen focus to DAW again. Is this possible from an ASIO driver? i.e. a) detect which window is associated with the driver host, b) listens the focus on this window c) switchwasapiExclusiveModeaccording to this focus -
detect when another software wants to play sound. Automatically switch
wasapiExclusiveModetofalse. -
if FlexASIO's buffer is
000....0000during 5 seconds, this means no audio is playing, so we can "release" thewasapiExclusiveModetofalse, so that other software can use the soundcard. When the buffer is no more zero (audio is playing again), then reinitialize withwasapiExclusiveMode=true. This could be an option in the configuration:autoswitchExclusiveMode=true. -
change the 20ms of
wasapiExclusiveMode=falsein Windows registry. Possible?
Which option seems to be the best for you @dechamps?
Once again, this might seem like a small detail, but it's not: a perfect UX like this would totally solve this problem once for all for millions of PC users.
Oh, good to know! Is this documented somewhere? (if you have a link maybe?)
Not that I know of. I know Windows calls APOs with 20 ms buffers at a time, or at least they were when I wrote a custom APO some time ago. It's not possible to have less than 20 ms latency if any part of the processing chain accumulates a 20 ms buffer before processing it. That said, I've not looked at this recently, maybe that changed in more recent Windows versions.
Do you think this global Windows WASAPI parameter can be modified in regedit.exe or somewhere else? Or would 20ms be hardcoded in WASAPI's source code?
I don't know of any way to change the default buffer size of the Windows audio engine.
Is might already be on PortAudio project's todo list. If not, we could maybe post an issue there (maybe you have already mentioned this on their forum, if not I can do it?)
You can try posting on their mailing list. I wouldn't get my hopes up as there is very little activity on that project.
Yes and no, since thsee ideas are more general than keyboard shortcuts.
Which idea do you think would be the best?
These ideas have more to do with UX than with improving shared mode latency. I'll respond in the other thread.
Yes you re right, it's more about UX so it's probably better to answer there.
In Windows 10 Microsoft improved WASAPI by adding ways to achieve lower latencies in shared mode. Assuming that actually works on real systems with real drivers, that would solve your problem. However, I took a quick look at the PortAudio code and, sadly, it doesn't seem to support that extended interface. Someone would need to add that support, and I'm afraid I have no plans to do that anytime soon.
It seems like there's a chance that PortAudio might implement support for IAudioClient3 to reduce WASAPI shared mode latency.
See https://github.com/PortAudio/portaudio/issues/385 .
FlexASIO 1.7 comes with various improvements to the PortAudio WASAPI code that might make it possible to use smaller buffer sizes and achieve lower latencies, especially in Shared mode. See PortAudio/portaudio#303 for details. I would recommend experimenting with the new version.