Integrated, superior ASIO support for Windows clients

[danryu]

--> EDIT: Current installer HERE: KoordASIO_1.7a-k03_win64.exe <--

Hi all.
We at https://koord.live are big lovers of Jamulus and have been tinkering with some client code for a little while, and we have one or two things which we thought the community might benefit from.

Open-source ASIO
I've long considered it crazy that the best default solution to ASIO driver support on Windows was ASIO4ALL - a closed-source, rarely-updated single-client driver built using a deprecated API from Windows98 (WDM-KS).
While it is free, it is NOT particularly performant, and the lack of multi-client mode means that no other apps can use the sound device simultaneously. Which is the expected behaviour for the general user. I don't believe ANY user should have to install any other utilities (closed-source or otherwise) OR have any specialist knowledge about drivers just to run an app which requires ASIO. Not in 2021!
I started assessing open-source ASIO drivers last year, and since then it has become apparent that FlexASIO is the best of the bunch; it leverages PortAudio, uses WASAPI, the most modern, performant Windows sound API, is multi-client(!), and comes with comprehensive configuration options, documentation and a basic toolkit that allows integration with other apps.

But FlexASIO on its own has no configuration GUI and is far too complex for the general user.
So we at Koord forked FlexASIO to create a streamlined, simplified installation with a configuration GUI written in Qt: https://github.com/koord-live/KoordASIO
Please try out the beta standalone installer (64bit only): see link at top of post.

KoordASIO feature list:

• open-source universal ASIO driver
• uses exclusively the modern WASAPI Windows sound API
• Shared Mode - no more locking other sound apps by default!
• Exclusive Mode (fastest, locks other apps out)
• simple config GUI with sensible buffer sizes (from 32 to 2048)

Performance should in virtually all cases match or exceed that of ASIO4ALL, while also offering the important "Shared" mode.
In Exclusive mode with the FlexASIO/KoordASIO driver, users often report latencies around 5ms!
In Shared mode it is typically more like 20ms.
That's not all though! It gets better....

Integration
FlexASIO/KoordASIO can be quite easily integrated into any existing app that uses the ASIO SDK.
This means that we can build in an ASIO driver into Jamulus, so that there are literally no extra run-time dependencies at all, and the user can start using Jamulus "out of the box" after installation. Not only that, but it is more performant and feature-ful than the closed-source alternatives.
I have already done this with our fork of Jamulus, "Koord-RealTime" - it's only necessary to do some minor changes in the Jamulus Windows sound codebase and the build process in order to integrate this universal ASIO library into the Windows build of Jamulus. Please take a look! We have a working 64bit Koord-RealTime client installer with integrated ASIO here. (Note: this testing build assumes installation to default location "C:\Program Files\Koord-RealTime")
The driver is internal to Koord-RealTime/Jamulus and is thus not registered globally on the system. KoordASIO standalone and any other ASIO drivers can be safely installed and used alongside it.
No need for warnings about no installed ASIO drivers! There's always one built in.

Autobuild changes
No longer do we need to warn the Windows Jamulus user at any point about ASIO4ALL, which means we don't need the nsProcess part, which in turn means we don't need the complex NSIS installer code and can use a radically simpler installer like InnoSetup - also open-source, easy to do automated installation, and able to generate an installer with just a few lines of config.
I also optimised the Jamulus build somewhat on Windows, removing unused bundled DLLs for Qt and loading only specific MSVC DLLs, rather than using the vcredist tool which adds a lot of flab to the installer. The 64bit build of Koord-RealTime is now about 13Mb rather than about 75mb for the unified installer for Jamulus, if anybody still cares about filesizes :)
(I may produce a separate 32bit installer if I can be convinced that anybody still uses or needs 32bit Windows in 2021. When can we leave it behind??)

I look forward to any feedback from the upstream dev community.

[WolfganP]

Wow, excellent initiative. I'll surely try the compiled version you shared. Regarding performance, do you have any post comparing latencies and/or stating testing methodology?

[danryu]

Thanks @WolfganP, please refer to the upstream FlexASIO documentation on sound backends here:
https://github.com/dechamps/FlexASIO/blob/master/BACKENDS.md

And the author's particular notes on latency here:
dechamps/FlexASIO#8 (comment)

If you want to experiment more with the upstream project, FlexASIO also includes diagnostic utilities like FlexASIOTest.exe which you may find useful.

[pljones]

OK, downloaded from the installer link and ran the install.

I'd expected a standalone configuration app to get it set up, with that being offered on install. It wasn't offered and my guess at something begining with "koord" got me no matches from Windows apart from the installer.

So I tried running one of my DAWs (MuLab) and going into Audio Setup. The driver was listed, so I selected it and hit configure. Nothing happened. Hm.

Giving up on that option, I went to Explorer to look in the install directory and found an exe, kdasioconfig.exe, with a hopeful name... Ran it and up pops the config window. Perhaps from the DAW it hadn't liked me having no input devices available to Windows... Anyway, I closed the config app and enabled a couple of (disconnected) inputs then ran the app again and they were there.

Then I ran MuLab again and tried Audio Setup. Still no luck there. I can select the driver but it's not integrating with the DAW. My (old) Echo AudioFire driver does (for the device); ASIO4All does (and I don't need to go enabling things in Windows with that); ReaRoute does (virtually). ASIOLinkPro doesn't (and StageLight doesn't when StageLight isn't running) - both complain. KoordASIO silently fails.

So I'll try Reaper... Same deal there.

KoordASIO settings:

Reaper shows this as:

And "ASIO Configuration..." is "dead".

I then started a new Jamulus profile for testing there and got similar results:

The "ASIO Device Settings" button is "dead".

[danryu]

Hi @pljones, thanks for giving it a go. You've reminded me that I naively hardcoded (for testing purposes) the kdasioconfig path for ASIO config. I'll update this with a dynamic path (I'm guessing you didn't install to C:\Program Files\KoordASIO).

Also thanks for your note about the configuration utility needing to run after install. I'll add this and also a shortcut for the config utility. Both big usability points.

Hopefully, once you have configured with kdasioconfig, you've got working sound with the driver.
The point you raise about ASIO4ALL not needing device configuration is true - the WDM-KS backend bypasses those settings (I could add WDM-KS as a backup mode in KoordASIO too - but would rather not).

There is some generic advice on the FlexASIO FAQ regarding this:
To fix most channel count issues, go through the Windows audio settings, or run mmsys.cpl, to access the relevant Windows audio control panel. For typical output devices, channel configuration can be changed by selecting the relevant device and clicking the "Configure" button. For other devices including input devices, the channel count can be changed in the device properties, "Advanced" tab.

[pljones]

Hi @pljones, thanks for giving it a go. You've reminded me that I naively hardcoded (for testing purposes) the kdasioconfig path for ASIO config. I'll update this with a dynamic path (I'm guessing you didn't install to C:\Program Files\KoordASIO).

Yes, I generally try to keep C:\Program Files for Windows itself.

Also thanks for your note about the configuration utility needing to run after install. I'll add this and also a shortcut for the config utility. Both big usability points.

Thanks!

Hopefully, once you have configured with kdasioconfig, you've got working sound with the driver.

Sorry, I didn't even try that - I ran out of time whilst trying to find why the device naming didn't match between what I had in the config and what I saw in the application.

The point you raise about ASIO4ALL not needing device configuration is true - the WDM-KS backend bypasses those settings (I could add WDM-KS as a backup mode in KoordASIO too - but would rather not).

Can't the set up get to the same API layer that Windows itself uses to set the devices up before choosing them? Once they're available via PortAudio / WASAPI, let that handle the actual I/O? But it makes it harder to use if I have to look in Windows Settings (picking the right "sound" settings page of the several available) separately from the driver itself. Maybe even a button to run mmsys.cpl and then refresh after it's closed?

[danryu]

Can't the set up get to the same API layer that Windows itself uses to set the devices up before choosing them? Once they're available via PortAudio / WASAPI, let that handle the actual I/O? But it makes it harder to use if I have to look in Windows Settings (picking the right "sound" settings page of the several available) separately from the driver itself. Maybe even a button to run mmsys.cpl and then refresh after it's closed?

Agreed, this needs to be streamlined as it will doubtless affect lots of users. I thought of the mmsys.cpl button too as a backup in case it's hard to automate. I'll iterate and update.
Thanks for the thorough feedback.

[danryu]

@pljones FYI I've updated the build to reflect all your points, I think.
Not sure about the refresh button yet - this might be trivial, might not.
Also there might be some more automation/streamlining to be done in configuring Windows audio settings.
For now I've done the mmsys.cpl shortcut button, opening on the relevant tab in each case.

Updated version here:
https://github.com/koord-live/KoordASIO/releases/download/v1.7a-k02/KoordASIO_1.7a-k02_win64.exe

[ann0see]

Installed KoordAsio and I must say, I‘m impressed by the GUI and all your work!

Unfortunately - as expected and also experienced with PortAudio generally - my internal soundcard and the PA API don’t like eachother. If I try to select my speaker & internal mic everything works as expected (=feedback). As soon as I select the headphones, restart,… I have no sound and an error message saying that the driver couldn’t be initialised. ASIO4ALL is a pain to understand and setup but doesn’t given an error.

I‘m unsure if anyone can help in my case (probably it’s an incompatibility with PortAudio + Connexant drivers).

Actually, I also don’t want to go through the debugging process ;-(

[ann0see]

Couldn’t 100% confirm if the 24 but issue is fixed however I now seem to have a clue on the device naming thing: if I switch to Englisch, Headphones/Speakers seem to have two different names. One name is the internal one used by the system "Kopfhörer", while the other one is shown on the UI "Köpfhörer". Maybe there is some kind of internal ID you can use which can‘t be modified and does not change if the system language is different?

[danryu]

This is (again) a weird one. One name shows one umlaut, another shows two!?
I suspect again a PortAudio internal naming quirk.
I take the WASAPI device names direct from the OS, so it's interesting that they seem to deviate like this. Perhaps I need to double-check with the PortAudio internal naming before configuring.

As I informed pljones below, you can generate some useful debug log very easily.
Just:

• touch empty file {HOME}/KoordASIO.log
• run your ASIO host as usual with the Kopfhörer/Köpfhörer device(s) configured

The resultant debug output will probably be very revealing.

[ann0see]

The one with two ö‘s was probably changed by me since Kopfhörer should only have one. I can give a log file, sure. However, I‘d rather prefer to E-Mail it to you and not publish it here.

[danryu]

Ok thanks, that's reassuring that it's likely a manual edit causing that issue. If you can run the test after using kdasioconfig to configure directly, that will limit the scope of the debugging.
You can send to my published profile email or to Koord's general contact: [email protected]

I'm thinking about a way to anonymize and automate log submissions, to help triage quirk reports (most likely PortAudio).

[ghost]

I have to make some disclaimers before I say anything because I may not know exactly what you are programming.
It appears that maybe you are programming in German. Maybe some libraries compliers linkers whatever are biased toward ASCII, and internationalization from German to English needs a bug report.

[jujudusud]

Hi here and thanks for all that stuff.
Why don't you directly code with WASAPI API instead of portaudio ?

[danryu]

Good question!
The main answer is that I am using the FlexASIO upstream repo for all the driver code - I don't touch the FlexASIO driver code at all in creating KoordASIO, I just trim out things that are unnecessary for the general user, and provide a config GUI.
So you have to ask the author of FlexASIO why he used PortAudio! It does give you a lot out of the box, I suppose...

Interestingly, there is a direct ASIO->WASAPI driver here: https://github.com/levmin/ASIO2WASAPI
However, it is unmaintained, doesn't support Shared Mode (a major feature of WASAPI), and I couldn't get it to run at all on initial tests. FlexASIO is quite actively maintained and has a LOT of documentation and surrounding help with it - including the trick by which we can load ASIO drivers internally into hosts, without installing them system-wide.

[danryu]

Updated the build as per feedback from @pljones, and release link updated.
New KoordASIO installer here: https://github.com/koord-live/KoordASIO/releases/download/v1.7a-k02/KoordASIO_1.7a-k02_win64.exe

[danryu]

Original post updated with current build,
Unicode support, upstream driver enhancements and GUI update.

[pljones]

v1.7a-k03

• Installer:
  Seems good now.
• Config page:
  Pretty nice - I'd like an "OK" button to close, not just the window manager's close window button.
• Launching config from a DAW:
  This worked from MuLab, Reaper and Jamulus.
• Device naming
  This still seems to be an issue. Here's what the config app shows:
  
  And here's how they show in MuLab:
  
  
  Here's Reaper's view:
  
  In Jamulus, no inputs/outputs are shown (but I think this is a Jamulus issue when there's only one stereo pair declared by the driver for each).
  I can't see those device names anywhere on the device itself.
• Enabling a previously disabled device
  I had to close and open the config app but it appeared then
• Changing the selected device / device naming
  The same device name showed in the DAW. That's disconcerting, as it's a meaningless name. Perhaps just use a fixed string (In 1+2/Out 1+2) if the string from the driver can't be used?
• Trying to use the driver in MuLab
  
• Trying to use the driver with Reaper
  
• Trying to use the driver with Jamulus
  

[danryu]

Great, thanks. Yes, the failure to initialize does suggest that there is a naming problem causing a snafu.
(Assume this is the same between Shared and Exclusive.)
I imagine it is a naming quirk within PortAudio causing this issue.

Luckily, I actually included a logging option in KoordASIO 1.7a-k03. I reintroduced the upstream functionality from FlexASIO - you just need to create an empty file at {HOME}/KoordASIO.log and run your chosen hosts as you did above. This will dump a lot of verbose debug to that file which most likely will identify the issue. Between myself, FlexASIO, PortAudio, a solution is fairly likely to bubble up.
(The file should be deleted for actual operation - logging will obviously slow things down.)

I may look at introducing further diagnostic utilities as a runtime "debug" option, if this will prove useful...

EDIT:
PS I'll look at including a "Close" button somewhere in the GUI that tucks in efficiently.

[npostavs]

• Changing the selected device / device naming
  The same device name showed in the DAW. That's disconcerting, as it's a meaningless name

Do you mean that when you change the device selection in the KoordASIO GUI the device name in the connected DAW doesn't change? I think that's because KoordASIO isn't sending ASIO events, i.e., this is not just cosmetic, getting the effect of changing KoordASIO params requires resetting from the connected program. At least, that's what I'm observing in Jamulus: I need to reselect the KoordASIO item from the device dropdown before changes will take effect.

• I can't see those device names anywhere on the device itself.

The device name you show looks like a string version of a WASAPI jack descriptor (see PortAudio docs and Microsoft docs), this only has a "location" (hence the "front left") rather than fully meaningful name. I think it's equivalent to what you see in the Windows sound device properties under "Jack Information" (screenshot, for example).

[ann0see]

Some comments on the new GUI:

1. Having buttons for shared/exclusive mode feels wrong. You don’t see which mode you’re in at first glance. I‘d suggest radio buttons (as you did before)
2. To avoid cluttering the GUI for advanced options, you could add a menu/button which just opens the config file in notepad. This would allow quick (advanced) configuration changes without the need of much GUI stuff.

[pljones]

Agreed on 1:

Current:

Maybe something more like:

[danryu]

1. Having buttons for shared/exclusive mode feels wrong. You don’t see which mode you’re in at first glance. I‘d suggest radio buttons (as you did before)

Understood. My background is in Unix backend and devops, so Windows GUIs are not my forte!
However, we do have a pro designer creating properly-designed GUI elements for this utility; this is being developed both for the general user and Windows audio hobbyists and professionals, and there is an expectation in this area for such utilities to be visually appealing and professional-looking.
The buttons I introduced are actually placeholders for some new chunky, illuminated buttons which I think will be very clear to all eyes. If not, well then we may have to make the GUI skinnable so that everybody is happy :)

2. To avoid cluttering the GUI for advanced options, you could add a menu/button which just opens the config file in notepad. This would allow quick (advanced) configuration changes without the need of much GUI stuff.

The point of the GUI is so that the general user can exploit the power of FlexASIO without having any underlying knowledge of files, APIs and suchlike. For technical types such as ourselves, there is always FlexASIO, FlexASIO_GUI and the joy of test-configuring device drivers with text files. If there are advanced options which are useful "levers" for a significant proportion of users, and are not just work-arounds for issues that can be fed and fixed upstream, then we will look at putting those in an "Advanced" section of the GUI (maybe hidden by default).

[ann0see]

Sorry for not having done the ASIO debugging yet. It’s on my todo list.

Nevertheless some further thoughts:

1. I think a wiki entry (e.g. in the Knowledge base) about KoordASIO would be good. Add a disclaimer that KoordAsio and ASIO4ALL might not work for every hardware, there might be bugs,… but contributions are always welcome (especially to move FlexASIO forward)
2. Integrating KoordASIO into Jamulus sounds interesting; however I don’t think it’s ready yet and personally, I‘d prefer @npostavs approach here: Attempt to use Portaudio (v2) #870 it’s more complicated but still feels more native. However, that’s a discussion for the future.
3. You should try to contribute as much as possible of your work into FlexASIO/Jamulus in my opinion. Having forks is valid in the FLOSs world, but still means that the community gets divided. The change from NSIS to another approach can be investigated, discussed and - based on an agreement merged. If it’s an improvement, I doubt anyone would object it.

[npostavs]

2. I‘d prefer @npostavs approach here: #870 it’s more complicated but still feels more native.

The main obstacle I'm seeing there is that the Portaudio backend doesn't seem to be working that well, even compared to ASIO4ALL. If the Flex/KoordASIO works better despite also using Portaudio it would be interesting to find out why (one possibility is that I based my work on older version of Portaudio; there's been a new release recently).

[danryu]

1. I think a wiki entry (e.g. in the Knowledge base) about KoordASIO would be good. Add a disclaimer that KoordAsio and ASIO4ALL might not work for every hardware, there might be bugs,… but contributions are always welcome (especially to move FlexASIO forward)

Thanks for the suggestion, we will follow this up.
I'm particularly interested in the possibilities for synergy between FlexASIO, KoordASIO, PortAudio, Jamulus and other FLOSS initiatives.
While the FlexASIO author has no particular interest in making a build for "general users", KoordASIO can fill that gap and also allow a much larger and more efficient bug reporting and triage system.
I have started to develop some ideas around an automated troubleshooting/debug/reporting system, which would minimize the onus on the user, and optimize the reporting path to KoordASIO where we can triage between the upstream FlexASIO and PortAudio projects as necessary.
I strongly suspect that many errors (such as the one pljones experienced in this thread) are small quirks (most likely in PortAudio) which will not need heavy dev time to fix. The biggest obstacle is simply reporting that there is a problem and supplying the relevant information most efficiently - and I think we can overcome this obstacle without too much difficulty.

2. Integrating KoordASIO into Jamulus sounds interesting; however I don’t think it’s ready yet and personally, I‘d prefer @npostavs approach here: [Attempt to use Portaudio (v2) #870](https://github.com/jamulussoftware/jamulus/pull/870) it’s more complicated but still feels more native. However, that’s a discussion for the future.

I didn't know about that effort - that's great, it's definitely an elegant solution if it can be made to work reliably.
The only drawback with a direct WASAPI approach is that you're then cut out of ASIO-world, which most Windows audio hobbyists and producers rely on for a lot of software and hardware products.
The good thing is that there again is a potential for synergy, through both projects using PortAudio.
Yes, PortAudio is responsible for many quirks and bugs - but by increasing the number of eyes on these quirks, and vastly increasing reporting efficiency, I think it's likely the situation could stabilize rapidly.

3. You should try to contribute as much as possible of your work into FlexASIO/Jamulus in my opinion. Having forks is valid in the FLOSs world, but still means that the community gets divided. The change from NSIS to another approach can be investigated, discussed and - based on an agreement merged. If it’s an improvement, I doubt anyone would object it.

We're certainly interested in submitting PRs upstream in all these projects: this discussion was a precursor to exploring that possibility. I am in communication with the FlexASIO author and will be collaborating regularly going forward (whether that means he wants PRs or not is another thing).
(Re: the NSIS thing - as a Linux devops engineer I think the Jamulus cross-platform auto-build system is very well-designed, clear and extensible. However, the NSIS stuff feels like over-engineering - compiling the nsProcess plugin as part of the autobuild so that the runtime installer can back up settings of a 3rd-party closed-source driver? It's classic "Heath Robinson" IMO. And bundling and distributing 32-bit binaries with every installer also feels wrong. However, I would rather just demonstrate that a successful alternative exists, and then submit a PR to maintainers if requested - rather than take initiative on the PR in the first place. I know how emotionally attached people can get to their code :)

[npostavs]

The only drawback with a direct WASAPI approach is that you're then cut out of ASIO-world

In theory that solution supports any of PortAudio's backends, including ASIO. It doesn't seem to work as well as Jamulus' current ASIO backend though (e.g., #870 (comment)).

[ann0see]

Concerning NSIS/Windows build:

I know how emotionally attached people can get to their code :)

I am not and since the original developer is not active any more, we can change it. But that’s another discussion then.

Yes, collaborating with PortAudio is great! I‘m sure we can do something about it ;-).