[LAD] Jack slower than realtime/debug mode

Jeremy jeremybubs at gmail.com
Sun May 23 01:44:35 UTC 2010


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20100522/29be36f5/attachment.html>


More information about the Linux-audio-dev mailing list