[LAU] multiJACK patch management: the first glimmerings of success

Chris Caudle chris at chriscaudle.org
Wed Apr 6 16:34:49 UTC 2016

On Wed, April 6, 2016 2:49 am, Filipe Coelho wrote:
> If you have jack clients or plugins that heavily rely on mutexes,
> semaphores, conditions, etc the same thing might happen.

That would be a buggy plugin design.
Seems it could be interesting to automate checking for some of that.  I
thought maybe nm could help.

I ran on a random LV2 plugin I had available and the first nm output from
the LV2 .so file was just "no symbols."  I tried nm -D and did get a list
of calls, but I forgot there would be a lot of functions used in plugin
setup that would not necessarily be used in the process() function (or
whatever the actual name is for the various plugin formats).
For example, I'm pretty sure the linuxdsp plugins are pretty high quality,
so I checked one of those and found these calls which are not real time
safe, so are probably just used in setup:
calloc, fflush, free, malloc, pthread_mutex_lock, pthread_mutex_unlock,

Not to mention all the graphics calls which are not going to be in the
processing function.

So is it possibly feasible to automate checking for non-realtime safe
function use in plugin binaries?  I'm pretty confident it would not be
difficult to do with source, especially if you took the manual path of
finding the processing function by inspecting the code.  Copy the
processing function into an editor and search for a list of known common
system calls which are not real time safe.  Maybe a little more difficult
if you wanted something to automatically parse the code and only look in
certain functions.

But that is a lot of trouble to get the code setup for every plugin you
might want to use, seems like something which can scan binaries in the
plugin directories would be much more useful.

Chris Caudle

More information about the Linux-audio-user mailing list