Christian, Yes the output I posted began just before pressing sufficient keys to trigger the failure event, ie laying my arm across the keys. Capturing only the key presses, the failure itself and subsequent recovery, approximately 11 seconds in all. Fortunately sysprof tool allowed capturing an interval like this.
Re gprof, as far as I can tell the code to generate the profile log is embedded in the host application and generates the profile output file only on a clean exit. It may not have worked for me since my Linuxsampler does not exit cleanly with ctrl-c (SIGINT). Using kill to stop LS the capture file probably would not get written, if indeed it does work with c++. FYI my LS does exit with ctrl-c after initialisation. After sending the lscp configuration file ctrl-c results in a ‘Stopping disk thread .. OK’ message and hangs. Not a big problem just not clean. Doug Sent from my iPad > On 29 Aug 2023, at 7:35 pm, Christian Schoenebeck > <schoeneb...@linuxsampler.org> wrote: > > On Sunday, August 27, 2023 3:36:50 PM CEST Doug Gray wrote: >> Christian, >> (Resend - apologies for the previous direct send to you.) >> >> Compiled LS with "-O3 -pg -g" flags. Discovered gprof does not work with >> c++ (c, fortran and asm only) wasted an afternoon, should have read the >> first line of the man page more carefully (doh). > > I'm pretty sure gprof works with C++ frontend as well, but like I said I > think > gprof was a dead end anyway (for the reasons described before), so never mind. > >> Oprofile needs to be compiled from source for my Os > > Yeah, oprofile needs some work to run *and* providing useful output. > >> but did find Sysprof available for quick install. I have attached a capture >> output summary that includes the failure mode I described previously. The >> summary zeros in on the heaviest loads. > > Looking at your data, did you capture the entire app's life time, that is > from > app start over instrument loading up to the point where rendering caused the > performance issue you reported? > > Because usually what you do is limiting eithering capture or afterwards > analysis to the time period where the actual performance issue happens. In > this case we are only interested in the period where playback happens and the > audio dropouts occur. > > We don't want to have the time periods in the analysis data where the > instrument was loaded, because that taints the picture. > > /Christian > > > > > _______________________________________________ > Linuxsampler-devel mailing list > Linuxsampler-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel _______________________________________________ Linuxsampler-devel mailing list Linuxsampler-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
