Plugin crashes with TWINE on X86

I’m currently developing a plugin which should run on ELK and Linux desktop systems. I’m using the TWINE library, as the plugin uses threads. In order to keep a common code base, i tried to compile TWINE for X86, as suggested here.

On the ELK system everything works perfectly. For Linux desktop, i cloned TWINE from the GitHUB repo, disabled Unit tests & Xenomai

option(TWINE_WITH_XENOMAI "Build with xenomai realtime thread support" OFF) option(TWINE_WITH_TESTS "Build and run unit tests" OFF)

and run CMAKE, make & make install. TWINE builds flawlessly. Including TWINE and building for X86 works also without any problems! So there are no build issues!
The problem starts when running the plugin. I’m currently using Ardour as my plugin host on Linux desktop. After start, Ardour scans the plugin path. When scanning reaches my plugin, scanning is stopped and the plugin cannot be found in the plugin list anymore. Re-scanning won’t help.

I’m creating a worker pool in the constructor of the Audio processor of JUCE. when i remove the “pool = create_worker_pool(get_nprocs()” call from the constructor, the plugin can be scanned and used again.

Since i can’t even attach to the Ardour process, there is no possibility i see how to debug the problem.
Any idea how to progress from here?

Hi @Tschem,
maybe you can try to move TWINE initialization from plugin constructor / factory function to a later point?

Are you able to use another host (e.g. SUSHI, Carla, etc.)?

I’m not an Ardour expert but what’s probably happening here is that Ardour is indeed trying to create an instance of the plugin while scanning. Also worth noticing that traditionally hosts like to be in control of threading and are designed with single-threaded plugins in mind, so handling multiple threads from your plugins might not wok the best on some hosts.

1 Like

Hi @Stefano, thx for the reply.
Multi-threaded plugins should not be a problem with Ardour, since it can handle the JUCE threadpool class. No issus there.
I tested with Carla, same result here. Plugin scan can not find my VST plugin, it just disappears from the plugin list. Once i re-compile without TWINE, the plugin pops up again after a re-scan.
It seems like it is not identified as a VST after compiling with TWINE :man_shrugging: .

Hi Tschem. For debugging plugins in regular hosts, I’ve had some luck with attaching gdb before loading the plugin (or scanning, as scanning usually loads the plugin) with gdb -p host_process_id, you might need to use it with sudo. Haven’t done that with Ardour though.

As for twine, it should work under x86 and regular linux, just tested it here actually. It would be interesting to hear if you are able to build the unit tests and build and run the stress_test under /test/stresstest. That is a separate program made to exercise the pool implementation under various conditions. You can just run it with no arguments and if that successfully counts upp to 9999, then the thread pool should work fine.

1 Like

First off: I managed to run the plugin without crash, although i have no clue why that works now.
Instead of a crash, no threads are created. i’m creating a workerpool instance “pool” with
pool = twine::Workerpool::create_worker_pool(get_nprocs());
and assign a worker for testing with
workerStat = pool->add_worker(foo, nullptr);
On ELK, workerStat is “OK”, on desktop workerStat is always “PERMISSION_DENIED”.

Running the Unit-tests results also is a failed test:

i checked for latest version of libpthread-stubs0-dev which is installed on my machine.

Thanks for the info. I do have a hunch on what could be going on here. Twine wants to set the scheduling of the threads in the pool to SCHED_FIFO, which is a realtime scheduling policy for best performance, and the same scheduling that jack uses in realtime mode. That is likely what is failing due to permisson errors in this case.

If you haven’t enabled realtime scheduling in your distribution, you should try doing that, jack should also benefit from that. Depending on you distribution it could be as easy as adding your user to the audio group (Ubuntu or Mint). More detailed info here


Thx a lot @Gustav and @Stefano, works perfectly now!!! :star_struck:
Problem is solved!


Fantastic, great news!

1 Like