Integration query

[danryu]

I've installed and run this with FlexASIO, and have to say this is very close to being a feature-complete solution for universal ASIO on Windows.

I'm interested in making a Windows build of Jamulus (https://github.com/corrados/jamulus) which integrates FlexASIO and FlexASIO_GUI, so that non-savvy users (ie most musicians) can have a seamless installation experience (as they would on MacOS).

I'm a Linux devops/backend developer and haven't dug in to Windows builds much. What would be the technical steps required in: a) integrating FlexASIO_GUI and FlexASIO installers b) making FlexASIO_GUI open on the usual "ASIO Setup" user button input c) removing external runtime dependencies (ie installing Net.Core) ?

With these changes in place, I can't see why anyone would ever recommend ASIO4ALL again on Windows. Having a full open-source solution in place would make it dramatically easier for open-source Windows audio apps to have a seamless experience for users.

[flipswitchingmonkey]

The easy part is the installer - flexasio GUI basically just copies a few files to a folder and creates a shortcut, that's all.

I'm not sure about the setup button - I think that'd have to be integrated from the FlexASIO side of things (they'd have to call the GUI from there, which should be easy enough if we just drop it all in the same or a defined location, possibly set through a registry key)

Removing .net would be tricky. As in, not possible without a rewrite. However tbh the app is pretty trivial, it's basically just reading portaudio infos and dropping them in a UI. you could just as well write the UI in any other framework (QT or whatever) and the logic is just a TOML writer in the end, which again is available for multiple platforms (or just write a plain text file). It may be possible to compile the whole thing into a static .exe, i'll have to look into that

[dechamps]

I'm not sure about the setup button - I think that'd have to be integrated from the FlexASIO side of things (they'd have to call the GUI from there, which should be easy enough if we just drop it all in the same or a defined location, possibly set through a registry key)

I'd be open to making a change to FlexASIO where it will detect if FlexASIO GUI is installed, and if it is, it will launch it instead of opening the documentation when the "control panel" button is clicked. Having a well-known registry key to locate FlexASIO GUI sounds good to me.

[danryu]

Thanks guys for your input.

@dechamps Your suggestion sounds perfect. Shall I create an issue on your repo to track?

@flipswitchingmonkey re Using another framework: as this is a Windows-only use case, it makes sense to keep it as "native" as possible, so QT etc wouldn't really add value. Also, having to install any external requirement (Net.Core, QT or whatever it may be) will kill the installation experience for a lot of users. A large proportion of people who want to use FlexASIO will probably be home musicians and producers, and 90% of them will want a simple and intuitive UI to set the most useful parameters - which FlexASIO_GUI already provides. I guess if a static exe could be built which wasn't equally as large as the Net.Core runtime installer (ie 30mb +), and we could thus keep the overall installer package size reasonable, that could be a fine solution.

Otherwise, I guess we're looking at rewriting in MFC/C++ (or whatever the framework happens to be called)? As I said, my knowledge of Microsoft builds (especially for desktop) is minimal.

[dechamps]

@dechamps Your suggestion sounds perfect. Shall I create an issue on your repo to track?

Filed dechamps/FlexASIO#92. @flipswitchingmonkey Feel free to comment with a suggested mechanism for FlexASIO to locate FlexASIO GUI on the system (e.g. registry key).

Otherwise, I guess we're looking at rewriting in MFC/C++ (or whatever the framework happens to be called)?

I haven't looked at this closely, but my understanding is that the modern way would be to use C++/WinRT along with WinUI.

[jacksongoode]

Any update on this end?

[danryu]

@jacksongoode No update from my side, though I have an open item on one of my Dev project TODOs, to implement what @dechamps suggests in the previous comment: a new lightweight config GUI implemented in C++/WinRT and WinUI.

The project is made easier by the fact that @flipswitchingmonkey has already made a working POC with FlexASIO_GUI. Have any free time on your hands? By all means, feel free to beat me to it ;)

[jacksongoode]

@jacksongoode No update from my side, though I have an open item on one of my Dev project TODOs, to implement what @dechamps suggests in the previous comment: a new lightweight config GUI implemented in C++/WinRT and WinUI.

The project is made easier by the fact that @flipswitchingmonkey has already made a working POC with FlexASIO_GUI. Have any free time on your hands? By all means, feel free to beat me to it ;)

That would be a massive undertaking for me at my skill level :) I can be patient.

[danryu]

I am looking at this issue again, and just tried running FlexASIO 1.7a in shared mode with WASAPI. The results were great - sub-10ms latency on generic Windows laptop hardware, running apparently without problems. This felt like a landmark moment - low latency audio with open source drivers on Windows. And in Shared mode - meaning that lots of usability problems for inexperienced users with Exclusive mode won't be a concern. And FlexASIO_GUI makes it a lot easier to experiment with different settings for development.

So I'm thinking again what needs to be done to ship FlexASIO with a simple config GUI in a lightweight package. FlexASIO on its own is 11Mb which is already quite a lot to add alongside an existing installer. @dechamps - how possible/easy is it to reduce that size? As WASAPI seems to be the most reliable way of getting low latency using FlexASIO, could the size be reduced by dropping support for the other APIs? (Not sure if it's possible to do a stripped-down compile of PortAudio libs, for example...) Any thoughts you have on this would be appreciated!

As for the config GUI, obviously it should also be a relatively small installation to make it easier and simpler for users. (ASIO4ALL packs everything into an installer of ~500Kb). Also it should be fairly "opinionated" and not let the user do too much! Limited options would be fine to start with. The earlier suggestion of WinRT/WinUI is still something I'm targeting when I have dev time available - it's a new framework for me though, so unless @flipswitchingmonkey feels like learning a new API for the hell of it ;) it will take a little time yet ...

[dechamps]

The results were great - sub-10ms latency on generic Windows laptop hardware, running apparently without problems. This felt like a landmark moment - low latency audio with open source drivers on Windows. And in Shared mode - meaning that lots of usability problems for inexperienced users with Exclusive mode won't be a concern.

Have you actually measured this (for real - not just blindly trusting FlexASIO's latency numbers)? I don't think sub-10 ms latency is physically possible in shared mode, because the period of the Windows audio engine itself is higher than that.

So I'm thinking again what needs to be done to ship FlexASIO with a simple config GUI in a lightweight package. FlexASIO on its own is 11Mb which is already quite a lot to add alongside an existing installer. @dechamps - how possible/easy is it to reduce that size?

There are a number of ways:

• Currently FlexASIO ships with full debugging information (PDB files) to help users with stack traces for troubleshooting. These PDB files are completely unnecessary for normal operation and can safely be removed. They account for most of the package size.
• FlexASIOTest and PortAudioDevices could be removed. Users could be told to download a separate package for those.
• The package contains its own copy of the MSVC runtime DLLs. They could be retrieved some other way instead.
• All of the above is included twice: one for 32-bit, one for 64-bit. If you only need to support one architecture, you could remove the other.

If you combine all of the above, you end up with about 1.2 MB, uncompressed.

If you want to go further, one could look into tweaking build options to optimize for size. One could statically link PortAudio into FlexASIO, which would likely enable some additional link-time code stripping. You could also, as you said, drop support for various backends in PortAudio.

Note that I won't do any of the above for the official FlexASIO package, because it would amount to dropping functionality or making things more complex for the sole purpose of shaving off a few MBs, which seems like a bad tradeoff to me. So if you want to do this, I'm afraid you're gonna have to make your own package. I would then have to ask you to change the name (e.g. by adding a prefix/suffix) so that users don't end up with weird conflicts when they install both the "official" FlexASIO and "your" FlexASIO on the same system.

[danryu]

Have you actually measured this (for real - not just blindly trusting FlexASIO's latency numbers)? I don't think sub-10 ms latency is physically possible in shared mode, because the period of the Windows audio engine itself is higher than that.

Nope, not measured it, and I wouldn't know immediately how to go about that on Windows. I meant more that I could achieve a setting which reported sub-10ms and I didn't experience issues.

* FlexASIOTest and PortAudioDevices could be removed. Users could be told to download a separate package for those.

What's the consequence of removing these two, for the end user?

* The package contains its own copy of the MSVC runtime DLLs. They could be retrieved some other way instead.

Again, without much OS or packaging knowledge of Windows - are these redistributable DLLs which may already be present on the system?

Note that I won't do any of the above for the official FlexASIO package, because it would amount to dropping functionality or making things more complex for the sole purpose of shaving off a few MBs, which seems like a bad tradeoff to me. So if you want to do this, I'm afraid you're gonna have to make your own package. I would then have to ask you to change the name (e.g. by adding a prefix/suffix) so that users don't end up with weird conflicts when they install both the "official" FlexASIO and "your" FlexASIO on the same system.

The steps you listed above to reduce the package to 1.2Mb are extremely helpful. I should be able to hack the build enough with that information. I understand that you don't want to introduce a more complex build process for what you see as a specialized use case. However, please bear in mind that ultimately, the users of your software are not likely to be other Windows developers. There is no sense in distributing debug binaries where they will never be used, for example. A good automated build system would relieve you of the problem of generating alternative builds. I may be able to help on this in the near future as well.

As you are the creator of FlexASIO, it would make sense for your "official" build to also be the best, mainstream one that the end user will actually download - and then that end user can finally have a viable alternative for ASIO4ALL ...

[dechamps]

What's the consequence of removing these two, for the end user?

For FlexASIOTest, it makes it more difficult to troubleshoot issues.

For PortAudioDevices, it would make it more difficult for users to customize their configuration to select a specific device. That's not really a problem if FlexASIO GUI is used (although maybe FlexASIO GUI depends on PortAudioDevices, I'm not sure - @flipswitchingmonkey should confirm). PortAudioDevices is also a dependency of at least one third party software (REW), which uses to power its own FlexASIO configuration UI.

are these redistributable DLLs which may already be present on the system?

They might, but you can't rely on that. If they are not present, then you would need to ask users to install the official Microsoft MSVC redistributable package. Some installers download it automatically if needed. In the case of the FlexASIO installer I went for the simpler, more straightforward approach of just bundling the DLLs directly; other approaches tended to cause problems for some users but I haven't looked too closely.

There is no sense in distributing debug binaries where they will never be used, for example.

The debug information is useful in some cases to troubleshoot user-reported problems. For example there were a couple of cases where I asked a user to run WinDbg or look at a stuck thread in Process Explorer and provide stack traces. It can also help developers of ASIO applications, who get stack traces from FlexASIO for free out of the box if they need to troubleshoot a compatibility issue with FlexASIO. Of course they could build FlexASIO themselves to get the symbols, but they're unlikely to bother, and the end result is that it's harder for them to work on improving FlexASIO compatibility.

I do agree that the PDB files are of no use to 99.9% of users. But they're only a few MBs, and this is 2021, not 1995. I like users to have as many tools as possible immediately at their disposal to troubleshoot issues, because they tend to have very little patience when I try to investigate problems with them.

A good automated build system would relieve you of the problem of generating alternative builds. I may be able to help on this in the near future as well.

Yes, I have it somewhere in my TODO list to build a CI/CD pipeline using GitHub actions that would be able to build and generate installers automatically, although I'm not sure when I'll get around to doing that. (PRs are welcome.) Even then, I'm still don't convinced I should provide multiple installers. I don't want to deal with multiple "variants" of the official FlexASIO distribution unless there's a very good reason to do so. Shaving a few MBs off the installer is not that.

[danryu]

Yes, while the "end users" are mostly technical users/developers who are working on solutions, the current build makes total sense.

I am looking ahead a bit to when the potential users could be grandmas and grandpas everywhere, using a piece of open-source Windows software that needs ASIO low latency. No such users are ever going to troubleshoot issues with you or anybody else, so any debug binaries or test and configuration utility is unnecessary.

At that point, it makes sense to distribute the "final product" installer, which should certainly not contain debug binaries etc. Despite it being 2021, yes - but not everybody is on fast internet connections in the world, and overall download sizes do count. Particularly when FlexASIO is included as an optional installation with other software (which I'm planning), and then problems caused by bloated installers start to compound.

With a good autobuild, you won't have multiple variants - you will have a production build, and a debug build, version-matched with every release.

On Thu, 17 Jun 2021 at 14:09, Etienne Dechamps @.***> wrote:

What's the consequence of removing these two, for the end user?

For FlexASIOTest, it make it more difficult to troubleshoot issues.

For PortAudioDevices, it would make it more difficult for users to customize their configuration to select a specific device. That's not really a problem if FlexASIO GUI is used (although maybe FlexASIO GUI depends on PortAudioDevices, I'm not sure - @flipswitchingmonkey https://github.com/flipswitchingmonkey should confirm). PortAudioDevices is also a dependency of at least one third party software (REW), which uses to power its own FlexASIO configuration UI.

are these redistributable DLLs which may already be present on the system?

They might, but you can't rely on that. If they are not present, then you would need to ask users to install the official Microsoft MSVC redistributable package. Some installers download it automatically if needed. In the case of the FlexASIO installer I went for the simpler, more straightforward approach of just bundling the DLLs directly; other approaches tended to cause problems for some users but I haven't looked too closely.

There is no sense in distributing debug binaries where they will never be used, for example.

The debug information is useful in some cases to troubleshoot user-reported problems. For example there were a couple of cases where I asked a user to run WinDbg or look at a stuck thread in Process Explorer and provide stack traces. It can also help developers of ASIO applications, who get stack traces from FlexASIO for free out of the box if they need to troubleshoot a compatibility issue with FlexASIO. Of course they could build FlexASIO themselves to get the symbols, but they're unlikely to bother, and the end result is that it's harder for them to work on improving FlexASIO compatibility.

I do agree that the PDB files are of no use to 99.9% of users. But they're only a few MBs, and this is 2021, not 1995. I like users to have as many tools as possible immediately at their disposal to troubleshoot issues, because they tend to have very little patience when I try to investigate problems with them.

A good automated build system would relieve you of the problem of generating alternative builds. I may be able to help on this in the near future as well.

Yes, I have it somewhere in my TODO list to build a CI/CD pipeline using GitHub actions that would be able to build and generate installers automatically, although I'm not sure when I'll get around to doing that. (PRs are welcome.) Even then, I'm still don't convinced I should provide multiple installers. I don't want to deal with multiple "variants" of the official FlexASIO distribution unless there's a very good reason to do so. Shaving a few MBs off the installer is not that.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/flipswitchingmonkey/FlexASIO_GUI/issues/8#issuecomment-863185036, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEOW7BU6EDUSTPV3MVGCHLTTHQZLANCNFSM4Q5ZJC6Q .

[dechamps]

No such users are ever going to troubleshoot issues with you or anybody else, so any debug binaries or test and configuration utility is unnecessary.

…but they don't really hurt, either. Unless you count a few MBs as "hurting", in which case, well, I think we'll just have to agree to disagree on that one. I prefer to just keep things simple.

Keep in mind that there's nothing stopping you from integrating FlexASIO into your own release pipeline, really. Just change the name of the ASIO driver to avoid conflicts (e.g. call it FlexASIO-Jamulus), build it as part of your own product, register the ASIO DLL using regsvr32 in your installer, and you're done. We don't need to agree on what the installer should bundle. You have your own product with your own installer and full control over it. With a sensible CI/CD pipeline that becomes even easier. You could even make this FlexASIO "mini-fork" part of your overall product installer instead of keeping it separate, which would be even more user-friendly, because this way they are only dealing with a single monolithic product that can be uninstalled/reinstalled as a single unit.

Taking this is a step further, you could even integrate your FlexASIO "mini-fork" further by not registering it as an ASIO driver on the system at all; instead, only your product would recognize it as an ASIO driver. (This is not something that the ASIO SDK can do out of the box, but that can be worked around - in fact this is precisely how FlexASIOTest works.) This way you would keep your product and FlexASIO tightly integrated and self-contained as a single unit.

[danryu]

Thanks for the tips on integration. I will probably have to check in with you again when I get into those details ...

On Thu, 17 Jun 2021 at 14:50, Etienne Dechamps @.***> wrote:

No such users are ever going to troubleshoot issues with you or anybody else, so any debug binaries or test and configuration utility is unnecessary.

…but they don't really hurt, either. Unless you count a few MBs as "hurting", in which case, well, I think we'll just have to agree to disagree on that one. I prefer to just keep things simple.

Keep in mind that there's nothing stopping you from integrating FlexASIO into your own release pipeline, really. Just change the name of the ASIO driver to avoid conflicts (e.g. call it FlexASIO-Jamulus), build it as part of your own product, register the ASIO DLL using regsvr32 in your installer, and you're done. We don't need to agree on what the installer should bundle. You have your own product with your own installer and full control over it. With a sensible CI/CD pipeline that becomes even easier. You could even make this FlexASIO "mini-fork" part of your overall product installer instead of keeping it separate, which would be even more user-friendly, because this way they are only dealing with a single monolithic product that can be uninstalled/reinstalled as a single unit.

Taking this is a step further, you could even integrate your FlexASIO "mini-fork" further by not registering it as an ASIO driver on the system at all; instead, only your product would recognize it as an ASIO driver. (This is not something that the ASIO SDK can do out of the box, but that can be worked around - in fact this is precisely how FlexASIOTest works.) This way you would keep your product and FlexASIO tightly integrated and self-contained as a single unit.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/flipswitchingmonkey/FlexASIO_GUI/issues/8#issuecomment-863211452, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEOW7FWXD7RL23SOAYJ5C3TTHVR5ANCNFSM4Q5ZJC6Q .

[danryu]

Closing and continuing at https://github.com/dechamps/FlexASIO/issues/127