error related to recent wine-update (wine 5.9-1)

Question

error related to recent wine-update (wine 5.9-1)

udaemon opened this issue 5 years ago · comments

Hi,
on my Arch Linux pc there’s a problem with airwave since the recent update of wine to version 5.9-1. when I try to open a project in Reaper DAW with bridged vsts the program is stuck loading it; the terminal output goes:

[udaemon@x270 ~]$ reaper 002c:fixme:ver:GetCurrentPackageId (000000000021FD10 0000000000000000): stub Airwave host endpoint, version 1.3.3error: wrong number of arguments: 6usage: /usr/bin/airwave-host-32.exe.so <vst path> <port id> <log level> <log socket path>003c:fixme:ver:GetCurrentPackageId (000000000021FD10 0000000000000000): stub

can someone else confirm this issue on their setup? are there any ideas to solve it?
thank you!
take care

Robbert van der Helm · Answer 1 · Tue May 26 2020 18:30:20 GMT+0800 (China Standard Time)

Just chiming in to say that this is an issue with winegcc in Wine 5.7+. I ran into this as well while I was working on my own Wine VST bridge. The workaround is to explicitly specify the correct calling convention. I created a bug report for this issue here:

https://bugs.winehq.org/show_bug.cgi?id=49138

durutti · Answer 2 · Wed May 27 2020 16:50:16 GMT+0800 (China Standard Time)

Weird behavior, two machines (ubuntu 18.04) both with wine 5.9 one with the airwave deb file installed 8 months ago and the other building airwave with cmake a couple of days ago. In the first maschine (deb) the plugins never open similar to what udaemon reports. On the second maschine (cmake build) only the 32-bit vsts work

John Ferguson · Answer 3 · Wed May 27 2020 23:42:04 GMT+0800 (China Standard Time)

It seems a little weird to me that Wine made this change, but going on the comment made by Zebediah Figura in the link posted by @robbert-vdh, it seems like a lot of code in the Wine tree was updated to explicitly use this calling convention.

See here: https://source.winehq.org/git/wine.git/commit/ed6a5e97e0

red thing · Answer 4 · Tue Jun 02 2020 09:56:48 GMT+0800 (China Standard Time)

That PR solves the new crash, but 64-bit plugins that used to work are no longer working.

John Ferguson · Answer 5 · Tue Jun 02 2020 09:58:46 GMT+0800 (China Standard Time)

@xdrie Could you be more specific?

Which plugins aren't working?
What error messages if any do you see (and where do you see them)?

durutti · Answer 6 · Tue Jun 02 2020 17:06:42 GMT+0800 (China Standard Time)

@xdrie Could you be more specific?

Which plugins aren't working?

What error messages if any do you see (and where do you see them)?

all 64-bit plugins (in this backtrace IK multimedia tape machine 80) produce a wine error. on the other hand 32 bits (addictive drums) work. This issue existed before your commit ( regarding the comment from robbert-vdh--- I dont now if it has been accepted)
backtrace.txt

DiligentKeyPresser · Answer 7 · Wed Jun 03 2020 00:46:36 GMT+0800 (China Standard Time)

I am currently having both troubles with 64-bit plugins and with Reaper stucking upon plugin load. I have current master build. Since PR #112 is not merged yet i am assuming that problem with 64-bit plugins is not caused by #112

red thing · Answer 8 · Wed Jun 03 2020 05:59:06 GMT+0800 (China Standard Time)

Yes, I tried building the package before your patch, and that issue (64-bit plugins not working) still exists.
However, your patch does appear to solve the issue with the 32 bit plugins on my system.

The problem with 64-bit plugins is probably separate.

durutti · Answer 9 · Wed Jun 03 2020 19:19:01 GMT+0800 (China Standard Time)

I am currently having both troubles with 64-bit plugins and with Reaper stucking upon plugin load. I have current master build. Since PR #112 is not merged yet i am assuming that problem with 64-bit plugins is not caused by #112

Rebuild with cmake and the SDK provided in the josephmartin09 comment here obiwanjacobi/vst.net#11 and the 32 -bit vsts will work again. However
it doent help with the 64-bit vsts error

John Ferguson · Answer 10 · Thu Jun 04 2020 05:05:12 GMT+0800 (China Standard Time)

I'm unable to reproduce that error with #112 . Addictive Drums 2 (64-bit) takes about 30 seconds to load, but it does load, and it does work.

For reference, I'm running on Arch Linux (kernel 5.6.14-arch1-1), wine version 5.9-1, DAW used for testing is Bitwig 3.1.3.

I also had zero issues with 64-bit plugins before this issue was opened. Seems like #109 is more relevant.

@durutti and @DiligentKeyPresser : Only hint I can offer you is that I used a different version of the VST SDK than the one recommended by @durutti. I found it in the issue tracker for this project: #92 (comment)

Pascal Gauthier · Answer 11 · Thu Jun 04 2020 13:09:03 GMT+0800 (China Standard Time)

#112 also fixed the issue for me.

I did a fork that added a "testing" component that shows Wine logs that helps pinpoint the issue: https://github.com/asb2m10/airwave

Don't forget to build with the debug flag otherwise the Wine stacktrace is useless; eg:
cmake -DCMAKE_BUILD_TYPE="Debug"

Then load the plugin from the command line:

$ export WINEDEBUG=fixme-all,warn+all
$ cd $AIRWAVE_HOME/bin
$ ./airwave-tester ~/.vst/$YOUR_PLUGIN

If it loads from here, you can discard wine compability issues... otherwise you can see the Wine logs.

durutti · Answer 12 · Thu Jun 04 2020 16:28:26 GMT+0800 (China Standard Time)

@j-n-f could you provide the SDK you used because I cannot download that SDK from the link provided in the specific comment
@asb2m10 I rebuilt airwave (from rdlie git) following your recommendation but I dont see airwave-tester in the bin directory. I still have an error message while scanning for a 64-bit plugin on mixbus. In additon this version of airwave doesnt seem to play well with 32-bit plugins. The scan time is high (without ever finishing)

Edit
@j-n-f Ok I found the 2018 SDK