ASIO4ALL 2.17 (March 4, 2026) notes:
This version officially supports Windows 10 and Windows 11. Also confirmed to work with Windows 7 and Windows 8, with some minor GUI visual artefacts, though. Report bugs to [email protected]!

All the changes from all 2.17 betas and a final release:

2.17 final (March 4, 2026) (changes since 2.17 beta 2):
- Squeeze another millisecond out of USB 1 audio device latency.
- Completely remove the legacy “Use hardware buffer” – option, along with the selection of 3 or 4 KS buffers. This is >20 years old stuff and does not serve any meaningful purpose on modern systems.
- Fix an issue where some audio inputs would not show up.
- Lower CPU utilization also in Wavert polling mode when “Low Power Mode” option is enabled.
- Improve input/output latency reporting.
- The installer now has a “Debug” option. When selected, a debug handler will be added, catching application errors instead of just silently crashing to desktop.
- Minor fixes for improved stability and performance.

2.17 beta 2 (February 14, 2026) (changes since 2.17 beta 1):
- The “Force WDM Driver to 16 Bit” – switch is gone. It had no real useful function anymore and most >16 bit devices do not support it anyway.
Instead, we have a new global option called “SPL Low Power Mode”.
What this does, when checked, is to lower the CPU usage in certain low load scenarios, allowing the processor to enter a lower power state. The backside being the impact of the exit latency from deep power states, which could lead to audio dropouts. After all, there are configurations where multiple kernel events are fired within one single millisecond – all of which need to be processed in time.
What you should do: try, if you can enable this option with no adverse effect on audio quality. If afterwards you experience intermittent stuttering, leave this option disabled!
Note that neither setting will increase/decrease actual CPU utilization in cases of high audio processing load. It merely determines how the main audio thread will spend its idle time.
- Fix various potential crash sources in a number of corner case scenarios.
- Fix old, annoying UI bug where device list items would not properly repond to enable/disable action, especially when the particular item is currently inactive.
- On-board audio inputs on Lenovo Legion are working now.
- Improve handling in case the current audio device is in use elsewhere, including by the dreaded MS GS Software Synth. Forced takeover became even more assertive.

2.17 beta 1 (February 4, 2026) (changes since 2.16 (June 28, 2024)):
- Re-wrote large portions of the WaveRT code, thus improving support for not just various on-board audio solutions. What didn’t work before has a fair chance of working now.
- Prevent performance drop when host application window is minimized or fully occluded..
- Remove disconnected BT devices from the WDM device list.
- “Allow Pull Mode” switch has been renamed to “Alternative Buffer Synchronization”, because this is closer to what it does. ASIO4ALL will pick the WaveRT buffering mode most suitable for any individual device. This checkbox lets you try an alternate mode for better or for worse.
- The “Buffer Offset” Slider in the “Options” section now only works per pin. Also, it has become unit-less. The range of the slider represents the entire circular buffer of the current pin, allowing you to apply an offset relative to the audio cursor. Use only to fix crackles due to synchronization errors between devices. Generally, this slider should remain in its leftmost (default) position, because most of the synchronization work is done automatically.
- Fixed numerous other little bugs here and there…
- Known issue: on-board audio input on Lenovo Legion shows “beyond logic”. IRP_MJ_CREATE for the pin is rejected when not issued by audiodg.exe. I’m currently at a total loss with this one. Also, the manual isn’t updated yet.

(Updgrades of 2.15-2.16 were released in 2022 and 2024 accordingly; you can find changelogs on their website or my threads here on audiosex; old classic 2.14 released in 2017)

 

Last edited: Mar 5, 2026 at 9:33 PM

Agreed. A4A is >20 years old stuff, etc... If you want good audio, then get good audio hardware from a OEM that puts as much into their ASIO drivers as they do into the hardware. A4A is not going to make up for shitty hardware/drivers in most instances...

 

Just this update is might be useful for some users.. I have Audient iD14 mkII, then I will probably expand channels by adding Arturia AudioFuse X8 IN with its HQ AD conventers for my 4 Behringer (and other future) analog/hybrid hardware synths ;D

 

I now use the “Steinberg built-in ASIO Driver” and when I need more performance,
I use “FlexASIO,” but I'll take a look at it anyway. ^^

Addendum: I tested it and FlexASIO offers better performance.
Cubase 15 Pro
(Buffer: 2048)
FLexASIO: Runs more smoothly and has fewer fluctuations.


ASIO4ALL: Runs less smoothly and has more fluctuations.

 

Last edited: Mar 5, 2026 at 10:25 PM

I truly don't mean to be a jerk. But A4A has always been garbage in my experience. Not sure what real world performance advantage it has

 

funny comments

 

I did some loopback tests (Win11, buffers from 64 to 512) with Reaper and FlexASIO gave lower latency than Asio4all.
Reported latency from FlexAsio is also more accurate than from Asio4all (and that is what I set Reaper to use).
I was surprised to see that Presonus drivers also have a fair amount of error at large buffer sizes (determined doing loopback tests)
And, despite what some say, I have never had WDM perform anywhere near Asio4All (or FlexAsio, of course).
I wish WDM WOULD perform a little better.
But Asio4all at least allows me to record without losing my mind, and without having to have my Presonus AR-8 mixer on :D

Asio4all also had a hard time with my Realtek "USB" ALC4080 (uses the USB bus, I believe), and often freezes for minutes when first enabled or settings changed, seemingly trying to get control of the hardware. (?)
But even with my good old Win10 setups Asio4all would sometimes take time to work on initial setup, but after setup it usually would be fine.

FlexAsio has no such problems and also instantly obeys block-size & format requests.
Reaper loads with whatever settings I have in FlexAsio when not requesting anything special.
FlexAsio GUI also opens when requested by Reaper.

 

I’ll just drop my two cents in this thread: there’s no such thing as a standard, 'cos every machine is its own beast. You can’t just use a ruler and expect everything to work the same way.

I’m still on Finale 27 while trying to wrap my head around Dorico. So yeah, I’ve got these massive sessions in Finale (ethnic, jazz, chamber, orchestral, hybrid scores), you name it. And the only way to open some of those sessions is with ASIO4ALL. I tried installing FlexASIO, but on my current machine it just wouldn’t work at all. Did everything: updated .NET Framework, updated Windows 11, tweaked OS settings… nothing. The funny part? On my older (and weaker) machine, FlexASIO ran perfectly, with killer performance... WTF!

And honestly, comparing ASIO4ALL with FL ASIO… there’s no contest. Some projects literally only open if I’m using ASIO4ALL (with the caveat that FL ASIO is actually a great option in general, because it’s an "ASIO" that lets you do pretty much anything on your PC!).

Bottom line: there’s no universal standard. Every machine has its own setup, quirks, and differences. You just have to roll with whatever works best for you. But hey, it’s worth experimenting: sometimes you’ll stumble on what gives you the best results!

 

I would love if it had the possibility to crank up buffers to 4096 instead of 2048.
On older hardware that makes the difference if I could open a project and run it or not.
That's why I use Flex asio in combination with flex asio Gui.

 

I don't know about Finale, but Pro Tools for instance expects a certain buffer setting. Pro Tools only runs at 1024 samples buffer. Anything else and it won't start. Possibly maybe Finale does the same? you could try to give flex asio the same buffer setting that asio4all had and give it a shot.
I did not know that there is that much difference between those asio drivers. I mean in a 'does not run' way. Sure, different settings and different latencies. I used to believe that these asio wrappers just translate asio to wasapi. So they do not directly talk to the hardware. Therefore I thought if one runs any other would run as well?

 

This. Ignore the numbers your DAW reports to you, what your OS reports to the DAW, what your driver reports to the OS. Software across N layers of indirection always lies. Loopback is the only way.

 

True story. Even the drivers of legit hardware lie to make it look better.
The Daw Bench site tested several dozens of interfaces. Besides RME and Steinberg, all of them lied.
But we need to give Asio4all and all the other Wasapi Wrapper some slack here: Those wrapper only know what time it's gonna take until the windows part (wasapi or directx) takes over. From there it's out of their hands. So I would not say those wrappers lie. They just cant report the whole roundtrip because they have not data about that.
The legit driver for hardware does though. So thats lying to the costumer.

 

(All the following comments are when using ASIO hardware drivers ONLY - I only record midi using FlexAsio, etc.)
But of course using the reported latency is a good idea for general use, because otherwise you have to manually adjust every time you change buffers, and usually if you are just switching between 128 & 256 there is very little difference.

But if you are recording something and can't use the interface as monitor, manual adjustment is a good way, especially if you've already got the latency offsets averaged & written down . There is still a bit of variation, but not enough to worry about.
Once you know the average over a few tests over time it's not worth running loopbacks again just to get it exact for this computer bootup, or interface power-on, or this phase of the moon...

 

Have you ever been a Windows98 user? I´ve started on XP but the way audio worked(with a good interface) on that old thing was nutz.
Sure we were hw limited obviously and also software...well in almost every way other than having no audio API. I´ve tried running it on a newer platform, it can run 4GB or even more ram with the patch, and it literally has latency in picoseconds with a 4ghz+ cpu. If i was into triggering hw...

 

Last edited: Mar 6, 2026 at 5:25 PM

Oh you can't imagine how we suffered before Windows XP. You will not ever feel the joy of making a parallel port midi interface work in dos together with the midi only version of cakewalk (witch was completely in ascii signs, no graphical interface, just ascii). Or trying to get any midi interface to work in Windows 3.11. And you won't feel the devastation after finding out that the timing is soooo bad that the only choice you have is to save up for a mac and a motu midi interface...
After Apple decided to go for PPC and therefore become even more expensive than those 68k machines, I gave PCs another shot. So I came back to windows 98 SE and Nuendo 1.0.
Thank my dark lord steinberg came up with asio drivers and vst plugins - because Microsofts implementation was a joke. Most don't remember today: MS had had audio plugins architecture. Direct X plugins were a thing and cakewalk run on those. But windows 98 MME drivers were so bad, they could only be used for winamp. Direct X sound output was OK for gaming, but even there the latencie was way too high. Coming from Amiga I wand the sound the moment I pull the trigger, not 120ms later.
So wasapi today is great. It's not as snappy as some Linux sound implementation though.
That's why I use batocera for retrogaming. It has lower sound latency than the windows implementation of retroarch.

 

even when i ran my M-Audio Audiophile cards, i got better results with A4A than the M-Audio drivers
now i have a audiophile PCI-E sound card, A4A works perfectliy fine for recording and mixing projects

its great if people have stuff that works better for your interface, but i wouldnt say its a bad product by a long shot

 

I just couldn't get FlexASIO to work in Bitwig, not for want of trying.

Does there exist a download for the FL Studio ASIO only, rather than having to install the whole DAW?

 

You’ll find everything you need on the sister site (v. 1.0.3). Other than that, you can download the free FL Studio, which comes with FL ASIO included in the setup. After installation, you can uninstall the DAW while keeping the driver installed