Crash on setting parameters via curve
Audio plugin bundle over the LV2 standard for Linux
Brought to you by:
sapista
EQ10QS (as well as all other variations) crashes Ardour when I just move the EQ curve around both in analyzer window and controls under it. There is no specific way to reproduce the bug, it happens spontaneously and only in Ardour. Other plugins (except those already known to be buggy) work well. Ardour says “Segmentation fault” on every crash and does not provide any reliable info on the problem. I'm using the latest 2.0 EQ10Q build from KXStudio repos, Ardour 4.6.22 (4.6-22-g141e6fb), Debian Jessie 64 bit and 4.1.0-0.bpo.2-rt kernel.
Does it happens every time or it is random? Are you using FFT (analyzer) when crash ocurs?. I'm not able to reproduce that crash in my systems. It maybe a problem related with libraries versions mismatch in your system. In order to check that, please can you try to run EQ10Q from compiled sources instead of KXstudio packages? To build eq10q in your system: donwload the last package, unpack it and build-intall ( cmake ./, make, make install).
This happens regardless of whether I use FFT or not and totally random, but usually when I set up about six bands. Also I noticed that the crash happens only on gain adjustments, not on changing center frequency, but I may be wrong. Compiling packages by myself seemed to fix the problem, but further testing is required.
Last edit: Alexey Polevoy 2016-02-03
I belive it is a problem related with libraries in your system. If working with the self-compiled version works well, then the problem should be reported to KXstudio. But, if with compiled version crashes again, I will start testing the plugin in a Debian box to reproduce the issue.
Where did you get Ardour? From KX studio or Ardour site?
Testing revealed that self-compiled version also fails. My Ardour is that from KXStudio, but falktx ships only official binaries, so it's equal to what you can get from Ardour website.
Last edit: Alexey Polevoy 2016-02-04
I've failed traying to reproduce this behaviour on my computer. Please, can you confirm if you are still experimenting issues?
Yes, I still experience (not experiment) the problem even after system reinstallation. Try adding many instances (more than five) and set up the parameters, this should reproduce the bug.
I'm not able to reproduce that behaviour on my systems and I use to mix with a lot of instances of EQ10Q (around 40). However, it is a main issue that deserves to be studied carefully. I've just realized that you are using a RT kernel, please can you try it again with a regular kernel? I had very bad luck with some of the RT kernel, so I think that giving a try with a regular kernel may help to track the problem.
Also, can you provide concrete info of your jack settings (buffer size, sample rate)? And one last think, You said that it seems the segfault only occurs when eq gain controls are being changed, can you confirm that?
No, I can't, the latency and amount of xruns are ridiculous in case of using non-RT kernel. JACK server just skips the buffers and mutes the audio from time to time when I'm on generic or lowlatency. Both recording and mixing are impossible with any other kernel than realtime. JACK settings vary between 128 and 1024 sample buffer, 44.1 and 48 KHz, and this has no affect on eq10q behavior. And yes, crashes occur only on gain adjustments. Also, the same behavior was shown by OvertoneDSP, so I think problem relates to some graphic lib that draws the EQ curve, possibly even OpenGL (sometimes Chrome crashes when using HW video acceleration). I think it's either some parameter corruption or just a lib version issue. Other plugins work great.
I upgraded the kernel to 4.4.0 and problem is never gone, so it's most possibly not the kernel.
Sorry for slow reply.
Last edit: Alexey Polevoy 2016-06-01
More users were claiming about crashes on debian based boxes, so I'm goning to run more intensive testing on debian.
How do I collect crash data? I did some Pascal coding during my early teens, I think I can help with debugging.
Hi, I think that this bug is fixed in SVN rev151. If you can give it a try to confirm if that is working or not this will provide the better help. Thanks!
After some tests and a talk with some user I consider this issue fixed.
This is not resolved. Version 2.2 still behaves like this.