multiJACK patch management: the first glimmerings of success - Linux-audio-user

6 Apr 2016

Chris Caudle wrote:
...
  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. Very much so.
There's a large spread of software in linux audio which isn't realtime
safe and correcting these issues is slow work.
Half of the battle IMO is the spreading the information about what
realtime safety is, why it is important, and how it should be achieved.

...
  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. In the case of C code it
usually isn't too bad, but for C++ code it is
still a very non-trivial task to perform the analysis even with the
source available.

As part of trying to correct these long standing issues within
ZynAddSubFX one of the tools that I wrote starting back in 2012 was
stoat: https://github.com/fundamental/stoat

This tool uses llvm/clang to consume the source code and then construct
the possible call graphs (missing only function pointers which are
nearly possible to statically analyse).
Using a combination of blacklists and whitelists you can say what
functions/methods *should* be realtime safe and which ones are not safe.
Based upon this information stoat identifies when a supposedly realtime
safe function could call an unsafe function.

This approach eliminates identifying calls to graphics libraries and
threading locks which are never involved in the jack process callback.

To clarify one other point in this thread, zyn is not absolutely 100%
realtime safe and stoat can certainly point out the few remaining issues
(there is a single location for memory allocation/deallocation which
needs to be corrected (NO LOCKS)).
Compared to yoshimi however it is an absolutely night and day difference.
Based upon checking yoshimi's git again it should be essentially equal
to the realtime safety that zyn had back at its 2.4.4 release:
(unsafe function call graph)
http://fundamental-code.com/2.4.4-realtime-issues.png
Compare that to what was achieved for the 2.5.0 release of zyn:
http://fundamental-code.com/2.5.0-realtime-issues.png

Around 80% of those issues have been resolved within zyn since then.

A similar analysis could be done easily on yoshimi following the
instructions in stoat's README if someone is interested.

--Mark McCurry

(I just subbed for this, so hopefully I haven't messed up the threading)