theNizo
Building/registering wineasio on wine >= 10.2
- Which distro do you use? Arch 6.13.6-arch1-1
- Which Proton or wine version do you use? Proton Experimental wine 10.3-1
- Do you use pipewire? Yes I do.
- did you choose the native JACK or pipewire-jack guide? I chose pipewire-jack
- What appears to be the problem? (Describe it as best as you can)
I couldn't build 32 version of wineasio but I managed to install it and now all the files needed are in the right directories. Now I can't register wineasio I know the errors in console will appear but my output at the end is "regsvr32: failed to load DLL library wineasio32.dll" and nothing else.
-
Did you notice any other unexpected behavior? I don't think so except the two errors I described above.
-
What did you try already? I tried to change from wine to wine-staging and i tried to register other wineasio dlls and it failed too.
-
Did you do any of the steps differently or leave them out? I ignored errores while trying to make 32 version and just copied the files to the right directories.
Sorry for not streamlining previous post this is my first time on Github and I rarely post on any forum. I'd like to inform that I'm not that experienced with linux since it's my second month using it but I managed to overcome most of the problems I encountered so far until now.
(Thank you. Now I can see the last 3 points. And no worries ^^)
So you have compiled them successfully and they exist in the correct locations.
~~I'm currently having problems building them myself~~, so something has changed. I'll have to figure this out. But you can try the following 2 things in the meantime. EDIT: Can build now. I've replicated it. Trying to find a solution
1: Please run the following commands and make sure it doesn't say "not found" anywhere. (Running them one by one will be easier)
ldd /usr/lib/wine/x86_64-unix/wineasio64.dll.so
ldd /usr/lib32/wine/i386-unix/wineasio32.dll.so
2: I noticed that there's new directories inside /usr/lib/wine. This might be a change in wine. ~~You can try to add the files there too.~~ I have tried it and it doesn't make a difference.
# This would copy it from the place where we already placed them
sudo cp /usr/lib32/wine/i386-unix/wineasio32.dll.so /usr/lib/wine/i386-unix/wineasio32.dll.so
sudo cp /usr/lib32/wine/i386-windows/wineasio32.dll /usr/lib/wine/i386-windows/wineasio32.dll
This does not work for me, but I haven't yet figured out why exactly.
Yes they exist in the correct locations, I was following your guide step by step and I didn't have wine folder in lib32 (still don't my linux installation has it in "lib" folder so I put it there) and on wineasio github page it says that locations may vary.
1: Here's the output
[adrian@archlinux ~]$ ldd /usr/lib/wine/x86_64-unix/wineasio64.dll.so
linux-vdso.so.1 (0x0000709660094000)
libjack.so.0 => /usr/lib/libjack.so.0 (0x0000709660002000)
libm.so.6 => /usr/lib/libm.so.6 (0x000070965ff0a000)
libc.so.6 => /usr/lib/libc.so.6 (0x000070965fd18000)
libpipewire-0.3.so.0 => /usr/lib/libpipewire-0.3.so.0 (0x000070965fc5b000)
/usr/lib64/ld-linux-x86-64.so.2 (0x0000709660096000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x000070965fc2d000)
And the second one
[adrian@archlinux ~]$ ldd /usr/lib/wine/i386-unix/wineasio32.dll.so
linux-gate.so.1 (0xe803a000)
libjack.so.0 => /usr/lib32/libjack.so.0 (0xe7fae000)
libm.so.6 => /usr/lib32/libm.so.6 (0xe7eca000)
libc.so.6 => /usr/lib32/libc.so.6 (0xe7c97000)
libpipewire-0.3.so.0 => /usr/lib32/libpipewire-0.3.so.0 (0xe7be4000)
/usr/lib/ld-linux.so.2 (0xe803c000)
libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xe7baf000)
It doesn't says not found and as you can see I need to change directory my wine is not installed in /usr/lib32/ but in usr/lib/wine. Maybe this is the cause of my problems? I'm sure that I'm using multilib.
2: That's probably why I have it in usr/lib/wine/ rather than in usr/lib32/wine in first place. Maybe they changed something in wine.
I have the same problems mentioned here. I installed wineasio using the aur, but that should not make a difference, right?
Do you need any help collecting more data/info for this problem?
I have the same problems mentioned here.
I know. Everyone with the current package versions will.
Small info, I haven't looked into it a lot and nothing I've tried worked. Maybe an issue in the wineasio repo is needed? (I have no dev knowledge about wine.)
As a workaround, you could probably downgrade wine-staging (see Arch Linux Archive and its Wiki page). 10.1 is the last version it works with.
I can confirm i have been able to compile it by downgrading to wine-staging 8.9
What worked for me was creating a win32 wine prefix with ArchLinux packaged wine-staging
WINEPREFIX=/home/user/.wine32/ WINEARCH=win32 wine wineboot
Copying the wineasio32.dll and wineasio32.dll.so to /usr/lib/wine/{i386-unix|i386-windows} so it is properly detected by regsvr32 for the newer wine versions.
sudo cp /usr/lib32/wine/i386-unix/wineasio32.dll.so /usr/lib/wine/i386-unix
sudo cp /usr/lib32/wine/i386-windows/wineasio32.dll /usr/lib/wine/i386-windows
Then running the wineasio32.dll registration with:
WINEPREFIX=/home/user/.wine32/ regsvr32 wineasio32.dll
Finally, run the game with the created wine prefix:
PIPEWIRE_LATENCY="256/48000" WINEPREFIX=/home/user/.wine32/ wine Rocksmith2014.exe
You will get a message saying to make sure to have steam running but the game will still work just fine, I didn't tested the DLC stuff... But, RS_ASIO will work just fine again to get rid of the annoying latency :)
@jgmdev A significant part of this guide is keeping Steam integration, which you wouldn't get with this exact way. After a few quick searches, I couldn't find an easy way to create a 32 bit prefix with Proton (for this game only). Creating a proton prefix by hand and hacking together some way of Steam integration would take a few extra steps that I 1. haven't figured out yet, 2. don't know if I want to have them.
@theNizo Proton experimental already seems to use wine32 by default since there is a wine64 executable on ~/.steam/steam/steamapps/common/Proton\ -\ Experimental/files/bin and it is based on older wine v9.x
I tried the following, but...:
cp /usr/lib32/wine/i386-unix/wineasio32.dll.so ~/.steam/steam/steamapps/common/Proton\ -\ Experimental/files/lib/wine/i386-unix
cp /usr/lib32/wine/i386-windows/wineasio32.dll ~/.steam/steam/steamapps/common/Proton\ -\ Experimental/files/lib/wine/i386-windows
Then registering the dll worked:
WINEPREFIX=/home/user/.steam/steam/steamapps/compatdata/221680/pfx ~/.steam/steam/steamapps/common/Proton\ -\ Experimental/files/bin/wine regsvr32 /home/user/.steam/steam/steamapps/common/Proton\ -\ Experimental/files/lib/wine/i386-windows/wineasio32.dll
And here comes the but...:
WINEPREFIX=/home/user/.steam/steam/steamapps/compatdata/221680/pfx ~/.steam/steam/steamapps/common/Proton\ -\ Experimental/files/bin/wine VBASIOTest32.exe
While VBASIOTest32.exe shows the WineAsio device it doesn't produces any sound, I guess this is due to compiling wineasio against a more recent wine version than the one shipped with steam proton which is still on v9.x
I tried to see if I could modify the wineasio makefile to compile against the proton build of wine but sadly valve doesn't ships the needed header files on ~/.steam/steam/steamapps/common/Proton\ -\ Experimental/files/
Proton experimental already seems to use wine32 by default
That's the opposite of what I've read (1, 2; search for "wine64")
Then registering the dll worked:
That's actually useful, I'll try something.
[context VBASIO32] I guess this is due to compiling wineasio
I would guess it's because Proton makes it hard for you. Try adding this to the command: LD_PRELOAD=/usr/lib32/libjack.so
I would guess it's because Proton makes it hard for you. Try adding this to the command:
LD_PRELOAD=/usr/lib32/libjack.so
I did before posting the previous comment and sadly it didn't work.
I thought as much, but now I can confirm a workaround (tried on Arch Linux with packages up to date as of today):
- Downgrade to wine 10.1 (EDIT: here's everything needed for Arch)
- make wineasio
- copy wineasio (to old as well as new places)
- register wineasio
- update wine
- still works.
Still no known solution :(
There doesn't seem to be an easy way to downgrade wine on Fedora. I tried compiling the stable version and putting that version at the front of my path but it still used the staging version somehow. It seems winebuild is used in the Makefile but I don't have much experience with using wine, does anyone have any advice on this and/or how I might get the 10.1 version of winebuild?
There doesn't seem to be an easy way to downgrade wine on Fedora.
Honestly, what did I expect?
Remove wine.
Create a new empty folder somewhere (I chose ~/Downloads/wine-install).
Go here, download the following files and put them into the folder just created.
Should be ordered alphabetically, but no guarantee.
i686 (8 files)
wine-alsa-10.1-1.fc42.i686.rpm
wine-cms-10.1-1.fc42.i686.rpm
wine-core-10.1-1.fc42.i686.rpm
wine-ldap-10.1-1.fc42.i686.rpm
wine-opencl-10.1-1.fc42.i686.rpm
wine-pulseaudio-10.1-1.fc42.i686.rpm
wine-smartcard-10.1-1.fc42.i686.rpm
wine-twain-10.1-1.fc42.i686.rpm
noarch (17 files)
wine-arial-fonts-10.1-1.fc42.noarch.rpm
wine-common-10.1-1.fc42.noarch.rpm
wine-courier-fonts-10.1-1.fc42.noarch.rpm
wine-desktop-10.1-1.fc42.noarch.rpm
wine-filesystem-10.1-1.fc42.noarch.rpm
wine-fixedsys-fonts-10.1-1.fc42.noarch.rpm
wine-fonts-10.1-1.fc42.noarch.rpm
wine-marlett-fonts-10.1-1.fc42.noarch.rpm
wine-ms-sans-serif-fonts-10.1-1.fc42.noarch.rpm
wine-small-fonts-10.1-1.fc42.noarch.rpm
wine-symbol-fonts-10.1-1.fc42.noarch.rpm
wine-system-fonts-10.1-1.fc42.noarch.rpm
wine-systemd-10.1-1.fc42.noarch.rpm
wine-tahoma-fonts-10.1-1.fc42.noarch.rpm
wine-times-new-roman-fonts-10.1-1.fc42.noarch.rpm
wine-webdings-fonts-10.1-1.fc42.noarch.rpm
wine-wingdings-fonts-10.1-1.fc42.noarch.rpm
x86_64 (9 files)
wine-10.1-1.fc42.x86_64.rpm
wine-alsa-10.1-1.fc42.x86_64.rpm
wine-cms-10.1-1.fc42.x86_64.rpm
wine-core-10.1-1.fc42.x86_64.rpm
wine-ldap-10.1-1.fc42.x86_64.rpm
wine-opencl-10.1-1.fc42.x86_64.rpm
wine-pulseaudio-10.1-1.fc42.x86_64.rpm
wine-smartcard-10.1-1.fc42.x86_64.rpm
wine-twain-10.1-1.fc42.x86_64.rpm
cd into the folder and run sudo dnf install ./*
That should do it...
If this list is wrong for some reason, dnf will tell you which package you're missing.
Honestly, what did I expect?
Apologies, I didn't mean to start a distro war. 😅
Thank you very much for the steps, though. I was able to get wineasio installed and the test program works.
I ran Rocksmith using the start script and I'm getting the below error, is there something else I should try and/or should I make another issue for this?
Seperate issue please ^^ Don't know which wine version you used there. Safest bet would be to stay on 10.1 first. Follow this just to make sure: https://github.com/theNizo/linux_rocksmith/blob/main/guides/troubleshoot-no-sound.md and give me your RS_ASIO log.
I didn't mean to start a distro war.
It's not the first time I mentioned my preferences here. My comment was possibly unnecessary, yes. In any way, keep using what you like.
I just made Rocksmith work without having to keep my system wine to 10.1 using the following script.
WINE points to a folder where I extracted the wine-staging-10.1 Arch package (https://archive.archlinux.org/packages/w/wine-staging/wine-staging-10.1-1-x86_64.pkg.tar.zst) and the other variables are the same as your guide.
script_dir=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )
cd /tmp/
git clone https://github.com/wineasio/wineasio.git
cd wineasio
git submodule update --init
if [ -d $script_dir/patches ] && [ -n "$(ls $script_dir/patches/wineasio*)" ]; then
git am $script_dir/patches/wineasio*
fi
make PREFIX=$WINE/usr 32
cp build32/wineasio32.dll $WINE/usr/lib32/wine/i386-windows/wineasio32.dll
cp build32/wineasio32.dll.so $WINE/usr/lib32/wine/i386-unix/wineasio32.dll.so
cp build32/wineasio32.dll $PROTON/lib/wine/i386-windows/wineasio32.dll
cp build32/wineasio32.dll.so $PROTON/lib/wine/i386-unix/wineasio32.dll.so
if [ -d "$WINEPREFIX/drive_c/windows/syswow64" ]; then
cp build32/wineasio32.dll "${WINEPREFIX}/drive_c/windows/syswow64"
cp build32/wineasio32.dll.so "${WINEPREFIX}/drive_c/windows/syswow64"
else
cp build32/wineasio32.dll "${WINEPREFIX}/drive_c/windows/system32"
cp build32/wineasio32.dll.so "${WINEPREFIX}/drive_c/windows/system32"
fi
The wineasio patch used to make it build against a custom wine is quite trivial :
From 7e231273ef3009fd9dfc92af7a5b141b376fac5f Mon Sep 17 00:00:00 2001
From: Loic Bauer <redacted>
Date: Mon, 26 May 2025 19:09:21 +0200
Subject: [PATCH] Make the prefix configurable to use a custom wine
---
Makefile.mk | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/Makefile.mk b/Makefile.mk
index 991fd5d..abaccc1 100644
--- a/Makefile.mk
+++ b/Makefile.mk
@@ -14,7 +14,7 @@ endif
wineasio_dll_MODULE = wineasio$(M).dll
-PREFIX = /usr
+PREFIX ?= /usr
SRCDIR = .
DLLS = $(wineasio_dll_MODULE) $(wineasio_dll_MODULE).so
@@ -63,10 +63,11 @@ wineasio_dll_LDFLAGS = -shared \
-m$(M) \
-mnocygwin \
wineasio.dll.spec \
- -L/usr/lib$(M)/wine \
- -L/usr/lib/wine \
- -L/usr/lib/$(ARCH)-linux-gnu/wine \
- -L/usr/lib/$(ARCH)-linux-gnu/wine-development \
+ -L$(PREFIX)/lib$(M)/wine \
+ -L$(PREFIX)/lib$(M)/wine/$(ARCH)-unix \
+ -L$(PREFIX)/lib/wine \
+ -L$(PREFIX)/lib/$(ARCH)-linux-gnu/wine \
+ -L$(PREFIX)/lib/$(ARCH)-linux-gnu/wine-development \
-L/opt/wine-stable/lib \
-L/opt/wine-stable/lib/wine \
-L/opt/wine-stable/lib$(M) \
--
2.49.0
I did try it with a clean wine package, a clean proton (GE-10.3) and a newly generated prefix, so building the 64bit libs and using wineasio-register don't seem to be necessary.
I don't quite understand why you did it this way, since the point of staying on 10.1 was keeping regsvr32 in a working state.
That said
I was previously against copying the files by hand, since regsvr32 does more than just copying (https://en.wikipedia.org/wiki/Regsvr32). However, if that's all it takes, I might recommend just copying them to the prefix until regsvr32 works again. Simplest way for now.
Finally updated the guide. I'd like to keep this issue open until registering works again.
~~Fedora users, please check if the path update is correct. I changed /usr/lib/wine/i386-windows/wineasio32.dll to /usr/lib64/wine/i386-windows/wineasio32.dll, which would be equivalent to the change on Arch. Haven't confirmed if it's correct on Fedora though.~~ Reverted, nvm.
Oh well, guess why I don't like just copying it by hand - I recently reinstalled my system and now the setup doesn't work.
Okay, this is weird.
Starting with a wine version later than 10.2, I did the whole setup and it didn't work.
Switched back to wine 10.1. built, installed and registered wineasio. Worked.
Then upgraded to the current wine version (10.8), built, installed and in this case copied wineasio. NOW it works!?
Just copying is not a fix.
It's weird indeed, I just did a fresh install of CachyOS, and installed wine-staging 10.8 along with the pipewire-jack libs.
Using the script I posted above everything works fine with GE-10.4 without needing to downgrade wine or using regsvr32.
It's weird indeed, I just did a fresh install of CachyOS, and installed wine-staging 10.8 along with the pipewire-jack libs.
Using the script I posted above everything works fine with GE-10.4 without needing to downgrade wine or using regsvr32.
I would like to add my experience to this. I am on EndeavourOS (Arch-based). wine32 (10.13-1) instead of wine-staging worked when trying to build libraries for wineasio. Followed the instructions in this repository and then had to manually copy 32-bit .dll and .dll.so files due to wineasio-register not working - I put them into system32 folder. After creating a launch script, I got sound and Rocksmith did not crash in comparison to LD_PRELOAD=/usr/lib32/libjack.so PIPEWIRE_LATENCY=256/48000 %command%.
