[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] High DSP load

From: josh
Subject: Re: [fluid-dev] High DSP load
Date: Fri, 23 Oct 2009 13:40:11 -0700
User-agent: Internet Messaging Program (IMP) H3 (4.1.6)

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

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.


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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]