Adding VST plugins stops engine. about bespokesynth HOT 21 CLOSED

I'm not currently set up or experienced in debugging on linux, so I don't expect to be able to investigate this in the short-term.

is this a new problem, or have you never gotten VSTs to work? it appears that @davephillips has gotten VSTs working in linux: https://linuxmusicians.com/viewtopic.php?p=114718#p114718

if it's a new problem, perhaps try rolling back to prior commits until it works again, to try to identify the commit which caused the problem? if you've never gotten VSTs to work, perhaps @davephillips can offer advice.

from bespokesynth.

I don't remember when it was happened. Yep, I'm gonna to rollback and find the case.

from bespokesynth.

Well, I rolled back to the almost first commit of VST support and still got this problem. @davephillips confirms that https://linuxmusicians.com/viewtopic.php?p=120474#p120474
I haven't clue where to look at, BespokeSynth is a big project. Maybe you give advice where to put breakpoints or what else?

from bespokesynth.

hmm. so, one important element I'll confirm, which should inspire hope, is that VST loading does indeed work on OSX and windows.

VSTPlugin.cpp should handle basically everything related to VST loading, so that is definitely the place to look. since things are locking up for you, mVSTMutex might be an interesting thing to take a look at.

another interesting angle would be to check out the extras/AudioPluginHost/ example within JUCE, and see if it allows you to load VSTs. if it does (I would assume it probably will!) that indicates a difference between how Bespoke is loading VSTs and JUCE's example, so it would be interesting to step through the differences. if the AudioPluginHost does fail to load VSTs, that might instead point to an issue with JUCE, your linux distro, or something specific to your machine's configuration, which could be investigated independently of bespoke.

from bespokesynth.

Thank you for pointing. AudioPluginHost loads plugins and works at all, but it hasn't any transport.
BespokeSynth loads VSTs too and shows GUI of them, but suddenly stops transport, while pressing < and > in transport frame makes steps in it (I can record video, if it helps).
i wonder, what can make transport to "suspend" in BespokeSynth, mVSTMutex?

from bespokesynth.

rather than being a specific issue with the transport, I would presume that it's just the audio thread locking up. the transport is driven by the audio thread, so if the audio thread is frozen, the transport will stop moving.

you could try putting a breakpoint in VSTPlugin::Process() and seeing if it gets caught up on anything in there. the Process() method runs in the audio thread. additionally, the "root" of bespoke's audio thread work is ModularSynth::audioOut(), so you could trace through there.

the easiest way to see what's going on might be to break in a debugger when you're in this frozen state, and see what the audio thread is up to. my presumption would be that it's stuck acquiring a mutex somewhere.

from bespokesynth.

While I try to catch this with GDB I found that changing audio device has affect.
When I use my audio production PCI board in config, then adding plugins stops transport immediately. When I use some other (onboard SB) or virtual device such JACK - it possible to add couple of VST plugins, but on 3d or 4d adding it stops.
Ryan, did you test BespokeSynth with many VSTs?

from bespokesynth.

I have tested VSTs on mac and windows, but I don't run linux other than to compile bespoke, so I've never personally tested a VST in linux. I just tested now was able to just get 8 VSTs running on mac with no issue. I would be surprised if it's merely the number of VSTs you're using that's causing your issue... it seems like there must be some other factor affecting it.

from bespokesynth.

I think so too. Just observation.
Do you have any experience with gdb? Or if you'd use other one what would be the steps to catch the issue?
I'm playing with breakpoints and tracepoints but with lack of basic knowledge.

from bespokesynth.

no, unfortunately I don't have any linux development experience. I've only ever used graphical debuggers (within xcode on mac and visual studio on windows), never a text-based debugger.

my approach would be to break into the debugger when you get into the frozen state, and then look at what each of the threads are doing. this would likely reveal the issue. I presume that you would find the hang in the audio thread, it would be interesting to see what code it is stuck on. this is pretty easy to do with a graphical debugger, but might be a little tricker with gdb.

from bespokesynth.

nice idea, i'll install GUI frontend for gdb :)

from bespokesynth.

Greetiings ! I have generated a multi-threaded debug report with gdb, it's been posted at pastebin:

https://pastebin.com/8kQACmsg

Unfortunately I don't have a clue how to actually debug the application, but hopefully this report will help someone else. Btw, the program crashed when I selected "Scan for VSTs", I don't currently have any plugins listed with Bespoke.

I'm on Ubuntu 18.04.

from bespokesynth.

Hi,
Looks like you try to scan VSTs and host crashes with Odin2, I got such behavior too: Odin2.so doing smth strange with memory allocation I guess. You'd better try with strong production-ready plugins like LinuxDSP or Harrisson AVA VSTs.

But my case is not buggy .so (I hope). I started to play with Kdevelop and GDB and found:
When the added VST plugin stops transport juce throws this error:
JUCE Assertion failure in juce_Thread.cpp:100

in threads stack I see long list with depth of linux calls and BespokeSynth's method which writes used_vsts.json

Ok, I disabled this function:

root.save(ofToDataPath("internal/used_vsts.json"), true);

Tried again with similar steps: adding VSTs until engine stops and finally got big mess with (I think so) stalled futexes.

from bespokesynth.

I'm still struggling without much success. Another assumption:

Maybe there is race condition between ModularSynth::AudioOut and loader in VSTPlugin? For example engine became switched to paused on Plugin loading, then loader must trigger the engine but make that too early or didn't trigger at all. May it be timer related?

from bespokesynth.

I got my linux setup running again, so I was able to look at this! it's now hopefully fixed, or at least mostly fixed, in 3866fa4

it works when I tested it with https://u-he.com/products/zebralette/: before, it was freezing the audio thread, and after this fix it works now. the juce_Thread.cpp:100 you mention was the issue: something was throwing a bad_alloc exception in the audio thread, which was terminating the audio thread. my fix is pretty dumb and completely just a hack, but it seems to work for now, and can be investigated further later. it's possible (likely?) that it's not truly fixed, and I've only reduced the chances that it will occur.

it's possible that the Odin crash you mention when scanning is something separate, this change would not fix that issue.

from bespokesynth.

The problem is back. I have MS Windows with VS now and can reproduce on it too.

from bespokesynth.

strange, I have never experienced this on windows over the course of hundreds of hours of use... is there any specific VST in windows that you're seeing this issue with?

from bespokesynth.

Yeah, strange. I'll investigate -_-

from bespokesynth.

it's not always reproducible (as it was)
on windows loading u-he uhbik is most always stops the engine,
on linux i can catch with https://github.com/reales/OPL only, and it affected with my own build of plugin, so, i'm not sure where is problem

from bespokesynth.

unfortunately (or fortunately, depending on your perspective!), I am unable to get a freeze when loading any of the variations of uhbik, including all of the different letters, in either VST2 or VST3

from bespokesynth.

Cannot reproduce. Let's bury it again.

from bespokesynth.