[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,
Element
- [fluid-dev] [PATCH] sampledata caching, Kjetil Matheussen, 2012/10/09
- Re: [fluid-dev] [PATCH] sampledata caching, Aere Greenway, 2012/10/09
- Re: [fluid-dev] [PATCH] sampledata caching, David Henningsson, 2012/10/10
- Re: [fluid-dev] [PATCH] sampledata caching,
Element Green <=
- Re: [fluid-dev] [PATCH] sampledata caching, Kjetil Matheussen, 2012/10/10
- Re: [fluid-dev] [PATCH] sampledata caching, Kjetil Matheussen, 2012/10/10
- Re: [fluid-dev] [PATCH] sampledata caching, David Henningsson, 2012/10/12
- Re: [fluid-dev] [PATCH] sampledata caching, Kjetil Matheussen, 2012/10/12
- Re: [fluid-dev] [PATCH] sampledata caching, BCA, 2012/10/13
- Re: [fluid-dev] [PATCH] sampledata caching, David Henningsson, 2012/10/15
Re: [fluid-dev] [PATCH] sampledata caching, Kjetil Matheussen, 2012/10/10