On Sun, 3 Sep 2017 10:59:53 -0400 Mark McCurry <mark.d.mccu...@gmail.com> wrote:
>On Sun, Sep 3, 2017 at 10:19 AM, Harry van Haaren <harryhaa...@gmail.com> >wrote: >> 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 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. _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev