Re: [fluid-dev] High DSP load

[josh]

Hello Pedro,

Quoting Pedro Lopez-Cabanillas <address@hidden>:
> Hi,
>
> When using the Jack audio driver, watching the DSP load indicator in  
>  QJackCtl,
> running jackdmp 1.9.2 with no other Jack clients, playing a MIDI file with
> aplaymidi ...
>
> 1)
> $ fluidsynth -a jack -j -m alsa_seq -r 48000 -g .6 -p fluid
> ~/SoundFont/GeneralUser_GS_FluidSynth_v1.43.sf2
>
> 2)
> $ aplaymidi -p fluid AutumnLeaves.mid
> ( MIDI file from http://www.dougmckenzie.nl )
>
> Fluidsynth 1.0.9 = around 9% ( 8% < DSP load < 11% )
>
> Fluidsynth 1.1.0 (current SVN) = around 25% ( 23% < DSP load < 28% )
>
> The DSP load is the percentage relative to the period time of the total time
> spent by all clients to finish the processing of one period.
>
> The work done by FS is more or less the same for the two versions, so I guess
> that the extra DSP load taken by 1.1.0 is spent sleeping in mutex locks.


Strange.  Events are being passed in a lock free manner though (using  
atomic operations for lock free queues), so there shouldn't be any  
mutex locks.  There is some overhead in checking to see if the calling  
thread is the synthesis thread and queuing and processing the events,  
but this should be really minimal, though I have not yet run metrics  
on it, till now..

I just ran the identical test you described and see pretty much the  
same CPU usage for both 1.0.9 and 1.1.0 (as indicated by QJackCtl and  
top).  I'm not sure how trustworthy these values are though.  On my  
system I see in both versions an average of about 13-18% CPU usage in  
top (had to enable threads with 'H', or FluidSynth wont even show up).  
 I get some spikes in that song though, which can jump up to 36% or  
so and in a few cases I think its starving the CPU completely, since I  
get some crackling (too many voices), I've seen it jump as high as 80%  
in that case (on 1.0.9 in particular).
One strange thing I saw with top, is that the idle time + FluidSynth  
CPU usage doesn't add up right.  The idle time is higher than it  
should be.  This leads me to believe these values can't really be  
trusted, but I was glad to see very similar values between the 2  
versions.

I wonder what is causing the extra CPU usage on your system?  What  
kind of system is it?  Does it have multiple CPU cores?  One  
difference between the 2 versions is that in 1.1.0 all note-on events  
are processed within the synthesis thread, where as in previous  
versions, they could get executed in the MIDI thread.  This has the  
advantage of making all voices start synchronously and also made the  
task of making it multi-thread safe easier, but it also means that  
what could have been executed on a separate CPU (the note-on events),  
will now be executed on a single CPU with 1.1.0.  Overall this should  
be a similar amount of total system CPU usage, but it could  
potentially max out a CPU core easier.  You could enable multi-core  
support though, to give you more available CPU for voice processing.

One additional change that could be affecting things, is that there is  
now a synth.min-note-length parameter which is set to 10ms by default.  
 This means that if there were really short note durations that were  
causing a sound to be cut short, in 1.1.0 these voices may now have  
longer play durations.  I don't think that is happening though in that  
MIDI file, since the percussion still sounds the same.

> Regards,
> Pedro

Thanks for the testing!  I was hoping some others would help out with  
that process prior to releasing 1.1.0, to give me some more confidence  
and root out any bugs.  I still need to test FluidSynth with other  
applications like QSynth and Swami and what not.

Cheers.
Josh