Yes I knew all that. And if you already knew all that, one wonders why you were asking your questions in the first place.PurpleSunray wrote:It can, because it is a driver itself.whyterabbyt wrote: But VAC and such implementations are generally written for the OS-generic driver types, eg MME, not ASIO. Why is ASIO4ALL, which sits on top of a generic driver, capable of lower latency than the generic driver itself? There' a clue to your question in the fact that it is capable.
On user-mode you don't talk to a WDM driver, but to a user-mode API such as MME, WASAPI, DirectSound, HaveYouSeen.. This APIs are wired into the windows audio server, which does resampling, mixing and all that stuff and then it passes it down into the kernel mode.
This adds latency. So some guys invented ASIO and about 20 years later, Microsoft also added an offical interface to talk to the driver directly: WDM-KS
'KS' means "Kernel Streaming" and it is basically same ASIO: bypass user-mode stuff and send your audio to the driver directly.
Now.. what ASIO4ALL does, is that:
ASIO API [user-mode] -> ASIO4ALL [kernel] ->WDM driver [kernel]
It skips all resampling, mixing, .... done by windows audio server to get low-latency.
ASIO still doesnt do multiple drivers at a time, though. And VAC and the like still dont use ASIO.
It's the windows audio stack.whyterabbyt wrote: So whatever it is about generic drivers (eg MME) that makes them higher latency than the ASIO equivalents probably has an impact on virtual audio drivers, which generally get implemented for use with 'regular' window applications, not the high-performance-audio niche that ASIO serves.
Your audio driver most likely runs the exactly same code to transport audio for both, ASIO or via MME/DS/.. . It's just a differnt way on how it gets it data from user-mode land. With ASIO/WDM-KS data comes form the app directly (fast / low-lantecy), with MME&co audio travles through windows audio ecosystem (slow / high-latency)[/quote]
And again, answering your own question, in response to me answering it. I find that bizarrely pointless.
What was your point in asking what was happening again? Just avoiding dealing with the context, ie ASIO as a singleton driver?