Re: [LAD] DSP transients

2017-09-03 Thread Will J Godfrey 
On Sun, 3 Sep 2017 10:59:53 -0400
Mark McCurry  wrote:

>On Sun, Sep 3, 2017 at 10:19 AM, Harry van Haaren  
>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

Re: [LAD] DSP transients

2017-09-03 Thread Mark McCurry 
On Sun, Sep 3, 2017 at 10:19 AM, Harry van Haaren  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
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] DSP transients

2017-09-03 Thread Harry van Haaren 
On Sun, Sep 3, 2017 at 3:02 PM, Will J Godfrey 
wrote:
>
> On Sun, 3 Sep 2017 13:35:47 +
> Fons Adriaensen  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
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] DSP transients

2017-09-03 Thread Will J Godfrey 
On Sun, 3 Sep 2017 13:35:47 +
Fons Adriaensen  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 :(


-- 
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

Re: [LAD] DSP transients

2017-09-03 Thread Fons Adriaensen 
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,


-- 
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] DSP transients

2017-09-03 Thread Will Godfrey 
Does anyone know of software that can log these without significantly adding to
the load itself?

-- 
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev