Quoting Pedro Lopez-Cabanillas <[email protected]>:
On Friday, October 23, 2009, you wrote:
Quoting Pedro Lopez-Cabanillas <[email protected]>:
> On Friday, October 23, 2009, [email protected] 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
_______________________________________________
fluid-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/fluid-dev
