[LAD] DSP transients

Harry van Haaren harryhaaren at gmail.com
Sun Sep 3 14:19:12 UTC 2017


On Sun, Sep 3, 2017 at 3:02 PM, Will J Godfrey <WillGodfrey at musically.me.uk>
wrote:
>
> On Sun, 3 Sep 2017 13:35:47 +0000
> Fons Adriaensen <fons at linuxaudio.org> wrote:
>
> >On Sun, Sep 03, 2017 at 08:50:08AM +0100, Will Godfrey wrote:
> >
> >> Does anyone know of software that can log these without significantly
adding to
> >> the load itself?
> >
> >What do you call a transient in this context ???
> >
> >
> >Ciao,
>
> I'm particularly wanting it investigate the behaviour at note-on. If
possible,
> the absolute peak relative to the background working level. Also the
'shape'.
> Is it a flat topped lump, or a narrow spike over a few samples rapidly
fading
> down.
>
> I'm hoping that if I can see and (hopefully) understand exactly what is
> happening it will help me work out how to mitigate it, and indeed if
changes
> are really improving the situation. Currently my only form of test is to
run at
> the edge of getting Xruns - very many times :(


So the "poor mans method" that I'd first attempt is to just read the TSC
from the CPU
at the start of the process() callback, and then again at the end. The time
between them
is CPU "ticks" that it took to process the audio. So far so good.

To make this some bit more reproducable, you could consider some sort of
automated
tests, where the note-on events are generated inside Yoshimi itself, and
then correlate
the note-on events with the DSP load. (If one note isn't enough, send 2000
notes :)

If you keep an array of uint64_t process_ticks[], and each process() call,
increment to store
the next ticks value in the array, you have a lovely array afterwards full
of "ticks", which can
be plotted using your favorite plotting software ( fprintf(file, "%f\n",
value) to a file + Gnuplot is a good hack)

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.

HTH, -Harry

--

http://www.openavproductions.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20170903/2b997e83/attachment.html>


More information about the Linux-audio-dev mailing list