[fluid-dev] Fluid memory usage question

[Paul Giblock]

Hello everyone

First, thanks for the excellent library, especially Josh.  I am a
developer for the LMMS project (lmms.sf.net) and our next major
release will have a soundfont synth. This is where Fluidsynth comes
in.  The library sounds great, and performs well.  However, there is a
problem.

I won't go into the details of how we are using Fluidsynth, because
the problem exists in a more general case.   Fluid seems to
predictably consume/leak lots of ram.  I wrote a simple program to
exploit the issue.  I used two soundfonts: fluid's GeneralUser GM, and
one called VintageDreams from hammer-sound.  I can send the later if
you want it for testing. You can download the program source here:
http://rafb.net/p/XRPcMi91.html   I recently installed 1.0.8, and the
problem isn't nearly as severe, but please read on.

The demo program first loads a large soundfont - this is a good
baseline for a single file.
Unloads the soundfont, then loads a small soundfont - hopefully the
mem.usage will decrease
Unloads, and then loads the large soundfont again - hopefully, we
aren't any/much worse than after the first load.

Here is the consumption under the DATA column of 'top':

2548   - Fluidsynth created, no soundfonts loaded.
83m  (+83)   -  Loaded the 30MB GeneralUser GM, looks like 50mb of overhead
53m  (-30)   - Unloaded, the load the 3MB VintageDreams, constant 50mb
of overhead
83m (+30)   - Unloaded, load the 30MB sfont again, same size as
before. This is good
7782 (-83)   - Unloaded, load the 3Mb VintageDreams, where is it?
83m  (+83)   - ad nauseum
7792 (-83)   - ...
83m (+83)
7792 (-83)
83m (+83)

Interesting. I always noticed a 50mb overhead in 1.0.7, everything
seems right after the first three loads, then, VintageSynth all of a
sudden uses not much memory at all (consumption is only up 5k from
start-up, yet Vintage is 3MB).  So, in this case, it looks like the
opposite of a leak :)  I have no idea what happens if you try to play
notes at this stage.

You can compare this with the output from 1.0.7a.  For the process, I
ran: pmap | sort -k 2 to sort by size.  You can view the output here:
http://rafb.net/p/oXFm9113.html  The RES and DATA values are shown
above each iteration, then I show the bottom few lines of the sorted
pmap.  You can see originally that Fluid would consume more and more
memory while reloading soundfonts.   You'll notice that memory
consumption increases, with each unload/reload. It looks like this was
fixed after the initial bug report in November 2006. But in our actual
program, LMMS, the bug persists.

I reduced our plugin which uses Fluid down to the bare essentials:
new_fluid_settings() and new_fluid_synth() on construction
delete_fluid_synth() and delete_fluid_settings() on destruction

The only other code is when the user clicks to open a file.  The logic
is the same, if we've loaded, then we call sfunload().  Then, we call
sfload().  Oh, and there is a call to sfcount().

Yes, while running our program, the memory consumption more closely
resembles the original 1.0.7a results from the standalone test.
Again, this is at http://rafb.net/p/oXFm9113.html  The second time we
load GeneralUser, the consumption is significantly (around 45MB)
greater than the first time we load GeneralUser.  sfunload() is
definitely called before loading a new font.

FYI: When I was testing with 1.0.7a, I ran the code through valgrind,
interestingly, none of these messages appear in 1.0.8.  I will try
running valgrind on LMMS and hopefully isolate any Fluidsynth errors.
I've spent several hours looking at Fluid's source, and even more time
trying to isolate the problem on our application's side.  I'm willing
to help out because, currently, Fluidsynth seems unusable to us.
Unfortunately, I don't know how much I will be able to accomplish,
especially since I am unfamiliar with the codebase, and am already to
committed to other projects.  So let me know if I can provide any
information.  I'm particularly interested in knowing why Fluid's
memory usage is going between 83MB and 7.8KB, instead of 83MB and 53MB
as it does the first iteration.

Anyways - any help is much appreciated.

Oh, regarding FluidSynth's future.  I don't care if it is ported to
C++ or not, but: please do not depend on glib or Qt.  Fluidsynth is
very nice in that it doesn't pull in massive TK dependencies like Gtk
and Qt.  Our application, LMMS, is a Qt app and I would hate to make
our program pull in another (opposing) library.

Thank you,
Paul Giblock