3 Sep
2017
3 Sep
'17
10:04 p.m.
On Sun, 3 Sep 2017 10:59:53 -0400
Mark McCurry <mark.d.mccurry(a)gmail.com> wrote:
On Sun, Sep 3, 2017 at 10:19 AM, Harry van Haaren
<harryhaaren(a)gmail.com> wrote:
Thanks for the suggestions guys. I was rather hoping for something more
lightweight than Valgrind - last time I tried it (OK a couple of years ago) I
had horrendous problems - any form of stability even at 4096 frames was
debateable.
However I'm pleased to say running it today with the arguments suggested by
Mark was rather different (although I did have to run at 1024 frames to get the
Xruns down to a few handfulls). It's going to take me some time to work out how
to interpret them results though :(
--
It wasn't me! (Well actually, it probably was)
... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
This won't tell you *where* in the code the
issue is - but does give you a
reproducable test
case and some input on if DSP load is consistent. If you want to know
*where* in the code most of
the time is spent, then using linux perf tools or similar might be useful.
If something more fine grained is desired I had some luck using valgrind to dump
detailed statistics for every execution of the audio process() callback.
Valgrind will tell you where the problem is as long as it's CPU bound and
not memory/IO bound operations causing the issue.
This was pretty helpful for smoothing out some of the overhead that
ZynAddSubFX had
in older versions.
The writeup is somewhat rough, but my old notes for using valgrind to profile
transient CPU load are stored at:
http://log.fundamental-code.com/2013/09/07/profiling-realtime-code.html
--Mark