Re: [fluid-dev] High DSP load

[josh]

Quoting Pedro Lopez-Cabanillas <address@hidden>:
> On Friday, October 23, 2009, you wrote:
> > Quoting Pedro Lopez-Cabanillas <address@hidden>:
> > > On Friday, October 23, 2009, address@hidden wrote:
> > >> I wonder what is causing the extra CPU usage on your system?
> > >
> > > Nothing. The CPU usage is more or less the same for 1.0.9 and 1.1.0
> > > in my test
> > > system. I've reported differences in the *DSP load*, which is a totally
> > > different thing.
> > >
> > > Regards,
> > > Pedro
> >
> > I'm confused then.  How are you measuring the DSP load?  I know
> > FluidSynth has an internal load calculation and related API for
> > reading the value.  Are you referring to that?  Any tips would be
> > appreciated on replicating your test and measurements :)
>
> The "DSP load" is the value returned by the Jack function jack_cpu_load()
> "the current CPU load estimated by JACK. This is a running average   
> of the time
> it takes to execute a full process cycle for all clients as a percentage of
> the real time available per cycle determined by the buffer size and sample
> rate."
> http://jackaudio.org/files/docs/html/group__ServerControl.html#gfa6ab5ce0a3d2aafa2f761d91f433ed0
>
> My test was with JackDMP-1.0.9, 3 Periods/Buffer and 1024 Frames/Period.
>
> You can watch this value in QJackCtl, see the attached image.
>
> Regards,
> Pedro

Thanks for clarifying that.  It occurred to me later after thinking  
about it.  This may be related to what I mentioned before, about more  
event processing occurring in the audio thread, rather than other  
threads.  The most significant one I can think of is note-on events.

I'm not noticing much of a difference between the 2 versions on my  
system though, in regards to the DSP usage (as seen in qjackctl).  Its  
not more than 3% or 4% on my system, maybe less.  It seems like the  
spikes are even worse with the 1.0.9 version, but its hard to tell  
with this method.  It would be nice to have a command line application  
that would print the load on regular intervals so that better metrics  
could be calculated.  Do you know of any such program?  It would  
probably be trivial to write one.

I turned off queue-ing of events, which breaks thread safety but  
provides some metrics.  Seems about the same to me, but then again I  
don't see much difference between the 2 versions to begin with.

Could you try this?

Change the following at the top of src/fluid_synth.c:
#define fluid_synth_is_synth_thread(_s)     (fluid_thread_get_id() ==  
(_s)->synth_thread_id)
#define fluid_synth_should_queue(_s)   (!fluid_synth_is_synth_thread(_s))

To:
#define fluid_synth_is_synth_thread(_s)     TRUE
#define fluid_synth_should_queue(_s)   FALSE

The only other thing I can think of is that there is an extra function  
call in the synthesis loop to do a final mix down of the voices, but I  
can't see that contributing anything significant, except perhaps the  
fact that its mixing them down at the end (rather than after each  
voice, as in 1.0.9), which perhaps means more cache misses.  It would  
be easy to change that back temporarily to see if that is the source  
of the difference.

Another thing I noticed is that the DSP load percentage seems to be  
affected by other running processes.  When I was doing a build of  
FluidSynth I saw the DSP load go down by a good 8 or so percent.

Josh