|
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 timeit 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) FALSEThe 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
[Prev in Thread] | Current Thread | [Next in Thread] |