dechamps / FlexASIO

A flexible universal ASIO driver that uses the PortAudio sound I/O library. Supports WASAPI (shared and exclusive), KS, DirectSound and MME.
Other
1.29k stars 70 forks source link

On Windows ARM, the installer does not install FlexASIO 64-bit #206

Open dechamps opened 6 months ago

dechamps commented 6 months ago

In #205 @eguetta ran into an issue where the FlexASIO installer only installed the 32-bit version of FlexASIO, leaving out the 64-bit version. This results in FlexASIO being only usable in 32-bit apps and not showing up in the driver list of 64-bit apps.

The plot twist here is that @eguetta is running Windows ARM. This is very likely what triggered the issue. Most likely, FlexASIO's Inno Setup got confused and treated Windows ARM as 32-bit only.

This is a bug in FlexASIO's installer, perhaps even in Inno Setup itself.

As a workaround, Windows ARM users can manually register the 64-bit version of FlexASIO by following the procedure described at https://github.com/dechamps/FlexASIO/discussions/205#discussioncomment-7900338.

dechamps commented 1 month ago

I took another look at this. I think a fix for this is going to have to wait, for the following reasons:

  1. I don't have a Windows ARM device to test with, and it's not possible to set up an ARM VM on x86 hardware.
    • One way would be to set up a VM on Azure but that is less convenient, and potentially costs money.
    • On the other hand VAC did add support for ARM64 in its latest 4.70 version so it should be possible to use that for testing even in an isolated VM (assuming I get my hands on one) with no attached audio devices.
  2. Inno Setup seems confused by the whole thing.
    • But the good news is, Inno Setup people seem aware of this and have fixes coming up in the next version (6.3.0).
    • The Inno Setup upcoming release notes even acknowledge precisely this issue:

      If you ship x86 and x64 versions of your app in the same installer, the 32-bit x86 version may be chosen instead of the expected x64 version when running on Arm64 Windows 11

A stretch goal here would be to not only have FlexASIO work properly on Windows ARM64 with x86/x64 apps, but also provide an ARM64 version of FlexASIO, such that native ARM64 ASIO Host Applications can use FlexASIO. This should be a fairly easy addition to the above. One caveat is that currently GitHub Actions would not be able to run ARM64 FlexASIOTest due to actions/runner-images#768, but it appears that is being worked on as well.

So, TL;DR: the ecosystem is almost there, but not quite. Let's check again in a few months.

dechamps commented 2 days ago

Some notes to myself regarding Windows ARM64 binary setup:

Cutano commented 2 days ago

This is a bug in FlexASIO's installer, perhaps even in Inno Setup itself.

Yes, exactly. I am a Windows on Arm user, and got FlexASIO ARM64 built on my Arm device. I registered the dll following the procedure described at #205 and it worked fine. It could be a work around if you can provide an Arm64 bulid with a register script in future releases.

Cutano commented 1 day ago

I spoke too soon. After I manually installed FlexASIO, FlexASIOTest returned a PASS result, and the driver did appear in my DCC/VST software. However, it doesn't work properly. image

dechamps commented 1 day ago

got FlexASIO ARM64 built

What do you mean? Did you compile FlexASIO with a bespoke build config targeting ARM64?

After I manually installed FlexASIO, FlexASIOTest returned a PASS result, and the driver did appear in my DCC/VST software. However, it doesn't work properly.

Keep in mind that an x64 ASIO host application running under ARM x64 emulation (which is presumably what you're testing with) will not be able to load an ARM64 FlexASIO. You'd need to use a traditional x64 build of FlexASIO (which does work, it's just the installer that's broken). I believe an x64 ASIO host application may be able to load an ARM64X or ARM64EC FlexASIO, but I'm not sure as I haven't looked deeply into these topics yet. I'm waiting for GitHub to provide ARM runners (actions/runner-images#768) so that I can run some experiments.

To be clear, there are two separate issues with FlexASIO on ARM right now:

  1. The FlexASIO installer has a bug where it does not install the x64 variant of FlexASIO when it's running on Windows ARM.
  2. Currently there are no ARM FlexASIO binaries.

(1) is the most pressing issue because it's preventing FlexASIO from working with x64 apps on Windows ARM. Since most ASIO host applications are x64, this means FlexASIO is virtually unusable on Windows ARM, unless you use the workaround I provided in #205.

(2) is more of a nice to have I think because I would presume there are very few (if any) native ARM ASIO applications on the market, and if they are built for ARM64EC then they might be able to use x64 FlexASIO anyway.

Cutano commented 1 day ago

Thanks for the reply.

What do you mean? Did you compile FlexASIO with a bespoke build config targeting ARM64?

Yes.

Keep in mind that an x64 ASIO host application running under ARM x64 emulation (which is presumably what you're testing with) will not be able to load an ARM64 FlexASIO.

I believe this is why the Arm64 library failed to load. I will switch back to the x64 version of FlexASIO. If you need to run any tests on an Arm device, I'd be happy to help. :)

dechamps commented 1 day ago

What do you mean? Did you compile FlexASIO with a bespoke build config targeting ARM64?

Yes.

Nice! It's good to know that it builds (and works, according to FlexASIOTest) at least - that was not necessarily a given.

GEEKiDoS commented 23 hours ago

Thanks for the reply.

What do you mean? Did you compile FlexASIO with a bespoke build config targeting ARM64?

Yes.

Keep in mind that an x64 ASIO host application running under ARM x64 emulation (which is presumably what you're testing with) will not be able to load an ARM64 FlexASIO.

I believe this is why the Arm64 library failed to load. I will switch back to the x64 version of FlexASIO. If you need to run any tests on an Arm device, I'd be happy to help. :)

Hello! May you try to compile to arm64ec target instead of arm64 to see if it works under x64 a host for better performence?

source: Mixing Arm and Arm64EC-compiled code