Hello Paul, Again apologies for the late replies..
On Thu, 2008-03-13 at 15:50 -0400, Paul Giblock wrote: > 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 > It seems those web page reports aren't there anymore, so I wasn't able to look at them. My experience of top and other memory reporting utilities is that they are often misleading, though. It does look like you were looking at the resident memory, rather than virtual, so that is good. Last I checked, there were some issues with the FluidSynth instance itself in regards to a memory leak, but this was a very small one (a lot of memory leaks were fixed between 1.0.7 and 1.0.8). I wouldn't be surprised though, if you were experiencing another leak bug. I'd be curious what kind of output you got from Valgrind. At the moment I'm rather busy with work and with my other project (Swami), so I've been neglecting FluidSynth. I hope to change that in the coming months. If you sent me some concrete output from Valgrind, I'd likely be more inclined to jump into the issues now though, rather than later :) Cheers. Josh _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
