GxCreamMachine leaks signal between two separate plugin instances
sirsipe opened this issue · comments
Hi! I reported similar issues with GxAmplifier-X some time ago (https://sourceforge.net/p/guitarix/bugs/128/). I then moved to using GxPlugins and they seem to have the same issue. Basically it seems that multiple instances of (at least the) GxCreamMachine mess with each others signal processing. See the video: https://youtu.be/xKLFCqhoVQE
Hi
The problem is that I can't reproduce that behaviour. There is as well not a single static variable in those plugs nor anything they been able to share. As you could see, there is nothing leaking from the plugin instances here on my setup.Sorry.
I understand it is impossible to fix unless it can be reproduced. However, like shown in my video, the leakage is real.
I had to find a quick fix for it so I verified the issue by changing gx_CreamMachine code to introduce it as new LV2 plugin called CreamMachine2, rebuilt and installed it. I can now have GxCreamMachine on left channel and GxCreamMachine2 on right channel and I have no leakage of the signal anymore. So this verifies 100% that there is some sort of issue using the plugin as multiple instances.
But, do you know what that means?
What did you all change to make it CreamMachine2? Only the name in the ttl file, or do you change all namespaces inside the C++ files.
I have quite low-ish knowledge on LV2 but luckily I happened saw some YouTube series about it some weeks ago. I changed the TTL and also descriptor name at the cpp file. Then I changed the make script to produce gx_CreamMachine2.so (and also ...2_ui.so) etc and also changed the manifest to point to the correct object file. Then I installed it to ~/.LV2/gx_CreamMachine2.lv2/*
May I ask which sample rate do you use?
48kHz
Do you experience similar leakages within other hosts? Qtractor or Reaper?
I've only been using them in Carla and Ardour under Ubuntu Studio. With Carla I've had no issues but also it's way harder to see any potential leakage between plugin instances with it.
I had to find a quick fix for it so I verified the issue by changing gx_CreamMachine code to introduce it as new LV2 plugin called CreamMachine2, rebuilt and installed it. I can now have GxCreamMachine on left channel and GxCreamMachine2 on right channel and I have no leakage of the signal anymore. So this verifies 100% that there is some sort of issue using the plugin as multiple instances.
The issue is that this shows that the issue is not inside the CreamMachine. What you changed was only the metadata provided information about the plugin to the host. Just using a different name for a plugin instance shouldn't make any difference at all.
Also, that you can't identify this issue in Carla, implies that the issue may be located in Ardour. It may be worse to reported there, in case it is the latest version of Ardour you use.
AFAIK difference between two different library modules vs two different instances of a module is the memory address space. The LV2 descriptor returns function pointers to e.g. static Gx_CreamMachine::run which routes the run for the instance given with the handle argument. If you have multiple instances of the same plugin, all those instances will share the same static routing functions and very close address space, and for instance potential uninitialized variables or overflow accessed arrays could easily "leak" data from instance to another.
When I created the secondary version of Gx_CreamMachine, I also built it as its own static library. So when gx_CreamMachine.so and gx_CreamMachine2.so modules get loaded, I believe they have completely different address spaces and even different static routing for their instances.
Since there is some history for GxAmplifier-X not handling Ardour's buffersize changes well in similar situation, this kind of feels plausible explanation for GxPlugins, too. Maybe buffersize goes down (or even zero for no-input-signal?) for a dsp run, but the signal is still calculated using previous buffersize -> accessing more array there was initialized -> potentially accessing old memory of another instance -> signal leak.
I'm sorry for throwing in my wild theories. A dev has a dev-mind, even when he has absolutely no idea what he's talking about ;) You may very well be right and the issue is in Ardour, but I'm still probably later going to take a closer look at the CreamMachine's code and maybe add some additional debugging information. Since I can reproduce the issue and happen to have somewhat decent C/C++ knowledge, I actually might have a shot tracking this one down.
Hi
So I found the culprit. There was indeed a global variable in use, I had completely forgotten about it.
Thanks for pointing out the issue. Please checkout latest version and let me know if it fixed that for you as well.
regards
hermann
The issue is fixed! Great work!
Again, huge thanks for these amazing plugins!