VST freezes on Arch

[mateuszmnm]

Steps to reproduce:

• start LMMS
• drag VeSTige into main screen
• click on VeSTige's green folder icon
• select a .DLL VST plugin

  Expected:

• loading plugin window appears
• plugin loads

  Actual:

• loading plugin window appears
• one of the CPU cores goes 100%
• LMMS stops responding
• it stays like that forever

Screenshot: http://i.imgur.com/2f5YURI.png Affected system: Arch 64 bit LMMS versions: 1.1.1, 1.1.2, 1.1.3 Wine versions used: at least 4 different - 1.6.4. 1.7.22, 1.7.33, 1.7.38 Example VST: Synth1 More details: https://lmms.io/forum/viewtopic.php?f=7&t=1749

Some strace dump: https://gist.github.com/obszczymucha/161b9fb25ce0a48b6af3 (it goes like that forever)

[thebeav26]

I am experiencing this issue still on Arch 64. According to this (https://github.com/LMMS/lmms/pull/2304) should the issue now be fixed in the git version of lmms? I tried building the git version last night (9Sep2015) and still had the same issue. Not sure if I had the lib32-qt4 package installed or not at the time, though.

Can someone please help with a workaround suggestion so I can use VST's?

[tresf]

Although #2304 potentially fixes this issue, it was never merged into our source code due to it breaking backwards compatibility for the old VST behavior.

If you clone the branch from the #2304 fork, you will have working VSTs. The author of that commit needs to make some changes before being accepted into our git source tree.

[thebeav26]

@tresf So I cloned @Narfinger 's branch and I'm still unable to load up Synth1. However, with the new version, it at least doesn't freeze the program in an infinite loop. You can continue using LMMS just fine after. In the terminal window I'm running LMMS from, I get the error message "remote plugin died! invalidating now." and then LMMS just goes on its way without loading the VST.

[tresf]

I assume you are using the fix-vestige branch? Perhaps he can help getting it running then...

[thebeav26]

Yes, I forked the main LMMS repo and then merged it with his fix-vestige branch.

[ghost]

Are you trying to load the 64bit Synth1? Try out with the 32bit version of Synth1.

[thebeav26]

@ichiman94 I tried both the 32 bit and the 64 bit *.dll's for Synth1 and a few other 32 bit VST's as well actually.

[thebeav26]

@Narfinger any ideas?

[Narfinger]

Sorry I do not have any idea why this does not work.

I got stuck trying to split the QSemaphore and QSHM code into separate classes because the shm code needs a bit more understanding and I did not have time yet.

Related to that I also tried using boost instead of Qt/linux native semaphores and queue. However, just using boost semaphore already gives me weird compile errors. Does anybody know if winegcc and boost are just incompatible? I really did not find much information on the net.

@thebeav26: I am also on arch so I am confused why it crashes for you as it worked for me. Do you have 32bit qt installed?

[Wallacoloo]

Pretty sure boost would be compatible with mingw (winegcc?), especially as its intention is to be cross-platform.

But I would be hesitant in adding boost as another dependency to lmms, on top of the already huge Qt. If you're just using it for semaphores, I'm pretty sure the c++11 std library includes those anyway.

[Narfinger]

The advantage with boost is that there is no linking dependency that is why I looked into it. Additionally, I was thinking that it might actually remove the FIFO implemented in the class entirely and replace it by a standard boost class that is thread safe. I will check if there is something in the c++11 std library for semaphores and shared memory.

I only know that when I tried including boost I got weird include errors which I could not solve (and didn't understand as it should have access to the .h files).

[zommuter]

Same issue here - just for the fun of it ran the Windows (64bit) version of LMMS via wine, where this works just fine...

[kernelcrasher]

I see that the split patch in #2390 has passed all checks. Does this mean merge and possibly VSTs loading correctly soon?

[Narfinger]

You are welcome to try but I wouldn't merge it into main yet. I still need to look at the problem posted by @tresf. I hope I can find time next week to check it but I cannot guarantee anything.

[kernelcrasher]

Thank you, and thanks a lot for the work.

[tresf]

I see that the split patch in #2390 has passed all checks. Does this mean merge and possibly VSTs loading correctly soon?

The mentioned PR doesn't actually address the VST bug yet per https://github.com/LMMS/lmms/pull/2390#issuecomment-148114571

So even when the Ubuntu 12.04 crash is fixed and the code split is merged, the option to use QSharedMemory (as opposed to the native IPC logic which is broken on some platforms, affecting Arch and a few others) won't be directly usable yet per this comment (unless I'm missing something):

I did not yet implement the switching to qt part. In essence this is just using defining the #define USE_QT_SHMEM and #define USE_QT_SEMAPHORES additionally, you need to link and include the correct Qt parts in plugins/vst_base/CMakeList.txt

[kernelcrasher]

From reading the linked issues, WineHQ and the Qt mailing list, it appears that the problem has its roots in the Qt implementation of a function called sendXEmbedMessage(). The arguments are actually passed in the wrong order, which causes everything to break. See: https://bugs.winehq.org/show_bug.cgi?id=35347 The issue was reported on the Qt bug tracker in 2014 and has remained unsolved to this day. (https://bugreports.qt.io/browse/QTBUG-36446)

Seeing as the Linux users are stuck with a bug that makes most virtual instruments unusable with an estimated time to fix of never, is it possible to figure out some workaround?

[Wallacoloo]

Given the name of the function ("X"), perhaps the bug can be avoided by running LMMS under wayland instead of X11?

[tresf]

@Wallacoloo perhaps, but if this is a Qt+Wine bug, I'm not sure how it broke yet again. Perhaps someone reverted the Wine code accidentally in a cleanup effort. I see mentions of QX11EmbedWidget going away with Qt5, so perhaps that's a more viable option?

[YvesPaultre]

So then, installing Qt5 and following the build instructions on the wiki might solve the problem? I'll give that a try and see what works.

EDIT: Apparently I won't. I broke my system trying to get build problems resolved. Gonna have to nuke it and reinstall Ubuntu, thank goodness I keep my home folder in a separate partition...

[amagnolo]

This affects also Lubuntu 15.10 x64 + wine-1.8 + LMMS 1.1.3 from kxstudio repositories. The tested VSTs (Synth1, Crystal) work all right when loaded in Carla instead of LMMS.

[kamnxt]

Affects LMMS 1.1.90 built from source with wine-1.9.6 on Arch Linux x64.

Tried both 32 and 64 bit VSTs.

[geldedus]

Affects LMMS 1.1.3 (Linux/x86_64, Qt4.8.6, GCC 4.8.2) on Ubuntu 15.10

[kernelcrasher]

It has been over a a year now. I was wondering if there could be some temporary workaround related to the Qt bug. Wouldn't it be possible to intentionally pass the arguments in the wrong order so that sendXEmbedMessage actually passes them in the right order? Also, it seems like someone on WineHQ has produced a temporary workaround: http://source.winehq.org/patches/data/101921 has this been tested?

[tresf]

has this [workaround] been tested?

Assuming it's the same bug, doesn't that require a patch to X11?

I was wondering if there could be some temporary workaround related to the Qt bug.

There is, @Narfinger wrote one https://github.com/LMMS/lmms/pull/2304.

Unfortunately, this was closed as the original author of the VST bridge didn't like the idea of pulling IPC support. That spawned a multi-step isolation process...

1. Step 1 - Split the code per https://github.com/LMMS/lmms/pull/2390
2. Step 2 - Make Qt method toggle-able

The first step had a bug which is explained the respective PR. No further progress has been made, but please feel free to hack away at it.

[amagnolo]

I'm sorry I don't understand, is there currently any way to use VSTs with LMMS in Linux? Or this feature is broken and was abandoned one year ago? What's the workaround to this bug, should I change Linux distribution, use an alternative to VeSTige, ...? Please don't tell me to install LMMS in Windows. ;-)

[tresf]

I'm sorry I don't understand, is there currently any way to use VSTs with LMMS in Linux? Or this feature is broken and was abandoned one year ago?

Unless using Carla, not that I'm aware of, at least not on most modern Linux versions (VSTs load fine on Ubuntu 12.04 for me).

What's the workaround to this bug

You could always clone and build the branch in #2304 and try that out, but of course that's not up to date with the stability changes we've had to master.

should I change Linux distribution, use an alternative to VeSTige

Or an alternative to LMMS, if it's a deal breaker for your needs. We need dev help on this.

Please don't tell me to install LMMS in Windows. ;-)

:)

[tresf]

Can someone please test this patch on Arch #2728

I'm testing on ElementaryOS Freya and it seems to be working so as long as I putting the linking back to the old method.

[liushuyu]

I also have the lastest Arch Linux, and I can test this out very soon.

[kernelcrasher]

Anyone tried the patch?

[liushuyu]

Anyone tried the patch?

I have tried this... No it didn't work...

[kernelcrasher]

The Qt bug report has been updated (https://bugreports.qt.io/browse/QTBUG-36446): apparently, they won't patch Qt 4 and Qt 5 doesn't have the functionality that allows for writing host applications. So, either this is fixed on the LMMS side by adopting some other way of using VSTs, or they will remain permanently unusable.

[jasp00]

According to https://github.com/LMMS/lmms/pull/2739#issuecomment-220817059, this issue is fixed.

[liushuyu]

According to #2739, this issue is fixed.

[keantoken]

I have this problem on Debian Sid, but only with a 64-bit VST.

RemotePluginClient::shmget: No such file or directory RemoteVstPlugin.cpp::shmget: No such file or directory RemoteVstPlugin.cpp: Failed to initialize shared memory for VST synchronization. (VST-host synchronization will be disabled)

The VST fails to load, and then 'wineserver64 -p0' turns into a zombie and eats my CPU. I am using VSTSynthfont64. The 32-bit version of this synthfont does have this problem.