<div dir="ltr">On Sun, Sep 3, 2017 at 3:02 PM, Will J Godfrey <<a href="mailto:WillGodfrey@musically.me.uk">WillGodfrey@musically.me.uk</a>> wrote:<br>><br>> On Sun, 3 Sep 2017 13:35:47 +0000<br>> Fons Adriaensen <<a href="mailto:fons@linuxaudio.org">fons@linuxaudio.org</a>> wrote:<br>><br>> >On Sun, Sep 03, 2017 at 08:50:08AM +0100, Will Godfrey wrote:<br>> ><br>> >> Does anyone know of software that can log these without significantly adding to<br>> >> the load itself?<br>> ><br>> >What do you call a transient in this context ???<br>> ><br>> ><br>> >Ciao,<br>><br>> I'm particularly wanting it investigate the behaviour at note-on. If possible,<br>> the absolute peak relative to the background working level. Also the 'shape'.<br>> Is it a flat topped lump, or a narrow spike over a few samples rapidly fading<br>> down.<br>><br>> I'm hoping that if I can see and (hopefully) understand exactly what is<br>> happening it will help me work out how to mitigate it, and indeed if changes<br>> are really improving the situation. Currently my only form of test is to run at<br>> the edge of getting Xruns - very many times :(<br><br><br>So the "poor mans method" that I'd first attempt is to just read the TSC from the CPU<br>at the start of the process() callback, and then again at the end. The time between them<br>is CPU "ticks" that it took to process the audio. So far so good.<br><br>To make this some bit more reproducable, you could consider some sort of automated<br>tests, where the note-on events are generated inside Yoshimi itself, and then correlate<br>the note-on events with the DSP load. (If one note isn't enough, send 2000 notes :)<br><br>If you keep an array of uint64_t process_ticks[], and each process() call, increment to store<br>the next ticks value in the array, you have a lovely array afterwards full of "ticks", which can<br>be plotted using your favorite plotting software ( fprintf(file, "%f\n", value) to a file + Gnuplot is a good hack)<br><br>This won't tell you *where* in the code the issue is - but does give you a reproducable test<br>case and some input on if DSP load is consistent. If you want to know *where* in the code most of<br>the time is spent, then using linux perf tools or similar might be useful.<br><br>HTH, -Harry<br><br>--<br><br><a href="http://www.openavproductions.com">http://www.openavproductions.com</a></div>