[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] [PATCH] sampledata caching

From: Element Green
Subject: Re: [fluid-dev] [PATCH] sampledata caching
Date: Tue, 9 Oct 2012 23:48:28 -0700

On Tue, Oct 9, 2012 at 11:05 PM, David Henningsson <address@hidden> wrote:
> On 10/09/2012 11:13 AM, Kjetil Matheussen wrote:
>> Hi,
>> I'm embedding FluidSynth as an instrument in the Radium music editor
>> (http://users.notam02.no/~kjetism/radium).
>> It works fine (thanks for the great work!), but the memory usage was
>> sometimes shockingly high because fluidsynth reloads
>> entire soundfonts for every new synth, even if the soundfont was already
>> used in a different synth.
>> Maybe I have misunderstood something, but instead of spending several
>> more hours trying to figure out if I had misunderstood
>> something, I modified fluidsynth to cache already loaded sampledata from
>> soundfonts.
>> Here's the patch:
>> http://users.notam02.no/~kjetism/fluid_defsfont_patch.diff
>> Please let me know if there's anything that's needed to do in order for
>> you to use it.
>> I also have a question: Can delete_fluid_defsfont and
>> fluid_defsfont_load_sampledata be called from different threads at the
>> same time?
>> In so, we also need a lock protecting the global list of cached
>> sampledata.
> Hi Kjetil and thanks for your patch!
> You're correct in your last sentence - as of how it works today, I'd say
> fluidsynth client software expects to be able to call fluid_defsfont_* in
> parallel. So yes, it needs to be protected.
> Another thing we need to verify is that the sampledata is read-only once
> it's been bigendian converted. If it is not, chances are that two threads
> would both modify the sampledata, causing problems.
> Element - you've been more into this part of FluidSynth than I, would you
> mind confirming that the sampledata is strict read-only and there are no
> hacks that change it?
> // David

Hello David, et al.,

I'm fairly certain once a fluid_sample_t is created and added to the
sample pool (using fluid_synth_alloc_voice), the sample data should
never be modified.  In fact I think this applies to the rest of the
fields in fluid_sample_t.  So if a sample's data or parameters have to
be changed, then new fluid_sample_t structures are created (possibly
pointing to the same sample data, if that is unchanged).  This is how
Swami does things at least.

Best regards,


reply via email to

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