Split from Windows 10 error opening or Internal PortAudio error[SOLVED] - #24 by Gale_Andrews
Thanks, Gale, but I am only interested in a version of Audacity with WDM-KS support. As you suggested yourself some time ago, WDM-KS support could be reintroduced as a special option not directly available in the default installation.
Well, personally I would just make an alternative build available at release time with severe warnings accompanying the link “audacity-win.2.1.1-experimental-wdmks.exe” (with additional debugging in if that was possible).
It would save all the messing with providing an interface in Audacity for users to switch WDM_KS on and off, or providing it as an installer option that users could easily switch on by mistake, or making it very hard by requiring editing audacity.cfg.
However the developers don’t like the idea of a separate release, and I don’t want to release a single Audacity with default enabled WDM-KS because of the blue screens it will cause on some machines, so it may take some time before there is any progress.
If you want to discuss WDM-KS further, let’s start a new topic.
Gale
It seems it might very well never happen. There isn’t a beta version with WDM-KS support, and from what you are saying, there won’t be any in any foreseeable future… How could WDM-KS support be developed/implemented if it isn’t tested?
There is nothing further to test until we attempt to implement debugging that “might” survive the crashes, or implement some fix. We already know what will happen with the current code.
We “might” find someone who would loan us their machine to debug on if we had some builds in circulation. It would be near impossible to go on just the sound device part number, even if a user gave us that accurate information. We probably need at least the exact same motherboard too.
Users of the one and only release build are not likely to take kindly to being used as the guinea pigs for our investigations.
As I said before, anyone is free to make their own personal Audacity build from source code with WDM-KS enabled.
Gale
+1 my thoughts entirely
We need some way of getting it out in the wild to get some real-word testing done -(it worked fine, mostly, on my machine when we had it in earlier alphas, it certainly didn’t give me the dreaded BSOD) 
Peter
It is a matter of how many PCs actually get BSODs because of WDM-KS. If it’s only 3 or 4% at most, I think it is worth including it in Audacity. After all, it is only an option in a menu. When users choose this option, Audacity could pop a message up, warning of the potential pitfalls of selecting WDM-KS as “Audio Host”.
The last time we released Audacity with WDM-KS (2.0.4) there were almost 500 users who reported freezes or blue screens that I almost single-handedly dealt with. I will not do that again - even the developers agree with me about that. We simply do not have the resources, without some automated support system.
There were about 10000 downloads of the unofficial 2.0.4 release “without WDM-KS” that I posted. So clearly large numbers of users were affected, even though it is a small proportion of the total. WDM-KS is useful, because it allows users of some hardware to record 24-bit or multi-channel, and has low latency, but it is an old API and likely to become increasingly incompatible.
So do you (Peter) support my idea of an alternative second release with WDM-KS enabled, clearly marked experimental? Otherwise, there won’t be enough usage of it to get enough people to give quality feedback. The point of not doing the main release with WDM-KS enabled is that we then don’t have to hand-hold hundreds of users of limited technical ability. We also don’t have to alarm users by saying that our main release carries a risk of blue-screening your computer.
Gale
To be clear, the necessary option is to enable the WDM-KS host then restart Audacity, which could blue screen the computer.
It still needs a developer to make those changes. I and at least one of the developers were in favour of doing this even as early as 2.0.5, but another of the developers is strongly opposed to this or any other method of selecting WDM-KS. He thinks it should simply be on by default and affected users are required to remain with the last version of Audacity that omitted WDM-KS.
Gale
If WDM-KS was an option, and people still chose that option despite the warnings, at worst they would get a BSOD. But BSODs aren’t such a big deal when the cause is known! People only have to reboot or press the reset button, and forget about WDM-KS when they use Audacity again. Maybe they could then send a detailed crash report to the Audacity developers.
As I said, the developers are not agreed about providing an option.
BSOD’s can sometimes cause system damage. And users can turn options on by default without reading the implications. We still have to help those users.
I recommend you build HEAD yourself with WDM-KS enabled. I have shown you what to change a while ago.
Gale
I have read the instructions on how to build Audacity from source, and add WDM-KS support, but I am not a programmer, and I would be out of my depth trying to achieve this. Or I would need baby-steps instructions that a toddler could follow…
+1
I do support this idea
Peter
Neither am I, but I still manage to build Audacity 
Programming skills are definitely not required.
The “nightly” builds are supposed to reflect what the users will receive when a release is made, so we should not turn WDM-KS on in alpha builds unless we are testing a fix for WDM-KS that we intend to release.
Gale