[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 11:47:22 -0700
User-agent: Internet Messaging Program (IMP) H3 (4.1.6)

Hello Pedro,

Quoting Pedro Lopez-Cabanillas <address@hidden>:

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

$ fluidsynth -a jack -j -m alsa_seq -r 48000 -g .6 -p fluid

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


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.


reply via email to

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