On Sat, May 22, 2010 at 9:44 PM, Jeremy <jeremybubs(a)gmail.com> wrote:
Hi,
I'm working on an lv2 plugin, and I'm having some difficulties debugging it.
What I would do is start up lv2_jack_host hosting my plugin, and then
connect it to an input. However, my plugin isn't returning in time (like,
*every single period*), so I get a flood of errors from jack. When I
connect it to my microphone, my system actually grinds to a halt, and I have
to sysrq in order to get it to respond at all. I also tried loading it as a
plugin within qtractor, which causes it to crash qtractor instantly when
connected to audio, with no trace.
Basically, my plugin right now is completely horrible, and I want to be able
to step through it handling one period. Normally I would just fire up gdb,
but with jack running in the background, it won't work. Within a few
milliseconds of gdb tripping a breakpoint, jack gets mad, and (I believe)
stops my plugin from processing to begin the next period. So basically, gdb
can't freeze the state, because as soon as I try to, it will unleash a flood
of jack errors.
What I am hoping for (and it doesn't look like I can find it) is some way to
make jack not run in real time, i.e. let it wait indefinitely for clients to
process. Obviously the audio output would probably not work, but at least
software wise, it seems like this could be viable. Alternatively, a similar
setup but on the lv2 plugin level would work, i.e. it could feed in audio
data and let the plugin process at whatever speed it wants.
Any other suggestions that would allow me to debug my plugin would be
welcome (well, besides "code better")
Thank You,
Jeremy Salwen
Take jack and hardware out of the picture entirely. For LADSPA
(version 1), there is a command line tool called applyplugin the reads
a WAV file, runs it through the specified plugin, and outputs another
WAV file. I'm not sure such a thing exists for LV2, but it should.
It probably wouldn't be hard to write. It's even easier if you just
read and write text files with floating point values in them (like
sox's dat file format).
Using such a tool, you would be able to step through your plugin code
in gdb as normal. You would also be able to use other development
tools like valgrind, etc.