"current system not supported" error

[Ryan Statz]

First off, I apologize if this has been double-posted (I just posted, but it doesn't appear to show up in any of the communities).

The issue is I keep getting a "current system is not supported" error any time I try to launch a .exe file -- specifically the XMOS audio control panel app/driver.  I am testing out a new SMSL RAW MDA-1 DAC/HPA, and this newer driver is supposed to fix the pop/tick issue with this unit.  The same error shows up with a .exe for a Topping DAC I have as well.

I'm using a Mac Mini M1 (2020), and my VMWare Fusion version is 13.6.3

If there's any information I'm missing, let me know and I will do my best to provide. Thanks in advance!

[Technogeezer]

I’m assuming that you are running Windows 11 ARM as a VM under Fusion since you are referencing .exe files which typically are a windows executables.

Have you verified with the software and hardware vendor that these applications and devices are supported under the ARM version of Windows? You also are mentioning drivers.  If you need a third party driver for a device on Windows ARM, make sure that the driver is specially supported and built for Windows ARM. Drivers built for Windows x86-64 won’t work on Windows ARM.

[Ryan Statz]

@Technogeezer

When I have VMWare Fusion running, it says "Windows 11 64-bit Arm" at the top of the window.

I have not verified that information as I have only just acquired the DAC/HPA device the other day, but the .exe itself would have been released on November 8, 2024 (that's the date indicated in the file name).  I am not so up on my Windows releases anymore, but I assume that if it was released 7 months ago, it should be compatible with the ARM version of Windows?  

The software in question is provided by the DAC/HPA manufacturer, and is labeled as a driver on their website, so that would be why I would be mentioning drivers. The file -- when unzipped -- is named:  XMOS_USBAudio_v5.70.0_2024-11-08_setup.exe so I do apologize if I've mixed up terms, etc...

By default, the DAC/HPA uses USB Audio Class 1.0, and this is supposed to enable UAC2.0 functionality.  Now, I have read that Windows 11 is shipped with a USB Audio Class 2.0 driver (in fact it was developed by the same company that developed the file I cited above), but the version mentioned above is supposed to enable an option in the XMOS audio control panel to set the DAC streaming to always on.  The reason the DAC ticks/pops is because by default, it "wakes up" when needed, and goes to sleep as soon as it's not.  So if a system sound is played, you will hear two faint ticks within a half second of the sound ending as the DAC goes to sleep.  If you listen to music, and pause, you hear the same two ticks.  There is also a bit of a delay as the DAC wakes up.  Setting it to be always on keeps it from effectively going to sleep, thus eliminating the ticks that are heard in those specified use cases.  And because it would always be awake, it eliminates the delay that occurs.  

This DAC/HPA -- should I choose to keep it -- will be used on the MacOS side of my Mac Mini, but I would still like it to function at its best if I am doing anything in the VM under Fusion.  I really only have to use a PC VM for instances like this where a manufacturer doesn't release MacOS versions of their devices' FW updates (like S.M.S.L.), etc... and other things like speaker design software (winISD), which isn't really available on MacOS. Because there are no required drivers for MacOS, there is no way to enable the DAC to always stream in any control panel, so the ticks/pops are on Mac side, too.  There's a workaround that involves running Qobuz in the background as it apparently sends a silent signal to the DAC, ensuring that it doesn't go to sleep.  I'm sure that there's some way to do it via Terminal, but I am deathly afraid to do any tinkering in that because I do not want to accidentally brick my computer.

This is just an issue that I have encountered before, for a very similar reason, so I was mainly interested to find out what caused that error notification.  I would also like to find a solution, purely to satiate my desire to solve the puzzle.  If you're amenable, I can (hopefully) attach the setup.exe file I mentioned above for you to check on your end because I feel like I'm not describing things clearly.  It could also potentially eliminate the question on the compatibility of the file if you had no issues running it on your end.  That could point to a setting or something else on my end.    

[Technogeezer]

I am not so up on my Windows releases anymore, but I assume that if it was released 7 months ago, it should be compatible with the ARM version of Windows? 

You can't make that assumption.  Unfortunately many vendors of devices with third-party drives haven't rebuilt their drivers for Windows ARM. Simply saying "Windows 11" isn't enough. The usual case is that means "Windows x86_64".

This sounds to me that either the .exe file is throwing the error because it is recognizing that it's running on an ARM CPU chip and not an Intel CPU or that the device doesn't have a driver attached to it.   There's nothing that you can change in Fusion to work around that. 

My advice would be to contact the device manufacturer to determine if they have or are planning a driver for Windows 11 ARM. 

The other thing to check is that the DAC device is being passed to the VM. You can check this by opening the Windows Device Manager and seeing if the DAC device can be seen.  My bet is that the device is there but doesn't have a driver -- or it has the Microsoft default driver. 

[Ryan Statz]

@Technogeezer

Thank you once again for taking the time to respond.

The DAC does show up in the Device manager, so it is being seen (shows up as SMSL DFU in Device Manager).  Also, in the VMWare Fusion top bar under Virtual Machine > USB there is an option to connect/disconnect a "Thesycon Systemsoftware & Consulting" driver for the DAC.  However, when I open the device manager, and open the Properties window, under the General tab, it says:

"The drivers for this device are not installed. (Code 28)

 

There are no compatible drivers for this device.

 

 

To find a driver for this device, click Update Driver."

Clicking on the option to update the driver yields a "Windows could not find drivers for your device" message.

If I select the Driver tab in the Properties window, and select "Driver details", it says:

"No driver files are required or have been loaded for this device."

I have e-mailed SMSL to see if they have a Windows 11 64-bit ARM driver available.  I have also asked them if they happen to have any audio control panel for MacOS because the pops/ticks are the result of the device's streaming option default of only being on when needed.  Having the ability to set it to always be on would eliminate all of the issues I'm having with this DAC.  It would save people the need to have to run an app in the background.  An unnecessary thing to have to do, given that the Topping gear I have does not exhibit that kind of behaviour, even on MacOS.     

[Technogeezer]

The DAC does show up in the Device manager, so it is being seen (shows up as SMSL DFU in Device Manager).  Also, in the VMWare Fusion top bar under Virtual Machine > USB there is an option to connect/disconnect a "Thesycon Systemsoftware & Consulting" driver for the DAC. 

The display in Fusion's Virtual Machine > USB  means that macOS and Fusion have identified the USB device and can pass the USB device to the VM. Connecting the device to the VM will disconnect it from the Mac -- it's not shared between the host and guest.  Essentially connecting the "raw" USB device will be passed to the VM as if it were connected to a physical USB port. Windows will need to provide a driver for the device at that point. 

However, when I open the device manager, and open the Properties window, under the General tab, it says:

"The drivers for this device are not installed. (Code 28)

 

There are no compatible drivers for this device.

That confirms my suspicion that Windows 11 ARM doesn't have an out-of-the-box driver for this device. And because it said "Windows can't find a compatible driver for this device" when you clicked on "Update Driver" means that Microsoft's Windows Update Service doesn't have one either. It's not uncommon for device vendors to send Microsoft a driver for Windows x86_64 that can be installed automagically. It is common that hardware vendors have not done the same for Windows ARM. 

Hopefully now that Copilot+ PCs based on Qualcomm ARM chips are becoming more mainstream, third party USB hardware vendors will get onboard with Windows ARM driver support. 

[Ryan Statz]

@Technogeezer

Thanks again, I truly appreciate the responses!

What I decided in the end was to return the SMSL device as the ticking/popping issue was too large of a hurdle for me to overcome.   I did reach out to SMSL about whether they had a driver that is compatible with an ARM-based system, but I have yet to receive a response.  Additionally (I should note that I do not have any of the tick/pop issues with the Topping gear), I reached out to Topping because it's the same issue with the driver not launching for their gear in VM, and they responded the next day with:

"Yes, the driver currently does not support the ARM-based Windows system. We will record your idea and feedback it to the R & D department. We look forward to having a product in the future that can meet your daily needs."

So, with a non-response from the company whose product I was trying to use on MacOS without issues that I believe are fixed on PC, back it went.