[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [iiwusynth-devel] Lates CVS changes
From: |
Josh Green |
Subject: |
Re: [iiwusynth-devel] Lates CVS changes |
Date: |
02 Dec 2002 21:44:21 -0800 |
On Mon, 2002-12-02 at 10:34, Peter Hanappe wrote:
<cut>
>
> API changes:
>
> - iiwu_sample_t: Added 'refcount' to indicate how many voices use the
> sample. Removed the 'valid' field.
>
Rock on! Is there a way to get notified with the SF loader API when a
iiwu_sample_t is no longer being used? This sounds like the right
direction for being able to smartly manage samples with Swami.
libInstPatch/Swami/GObject heavily uses refcounts by the way.
This is the feature I would most like to see in the new FluidSynth API.
More flexible sample handling would lead to a better Swami/FluidSynth
experience.
I would like to have 2 modes of sample management (3rd one is dreaming
perhaps for v1.0, but we have discussed it before) with the Swami
FluidSynth plugin.
- All samples are loaded and mem locked in RAM
- Samples are loaded on demand and cached
- Demand would be when a preset gets selected on a MIDI channel
- Unused samples would get unloaded based on different criteria
- Time since last used
- An used sample cache size variable
- Samples are streamed on demand, well perhaps for FluidSynth 2.0 :)
Just a callback routine for fetching the sample data might be
sufficient? Not real sure about the real-time implications of this.
- fluid_sample_data_callback (iiwu_sample_t *sample, int offset,
int size, char *buffer)
Perhaps the sample data un/load on demand could be handled by having a
"used" and "unused" callback for iiwu_sample_t structures in the SF
loader API. Once a samples refcount reaches 0 the "unused" callback
would be called. This routine would then have the option of unloading
the sample or doing so at a later time (perhaps just logging the time to
determine oldest unused samples). The "used" method would be called if
the sample gets used again (resetting timer, whatever).
A routine could then be supplied that would request the freeing of a
sample:
bool fluid_sample_data_request_free (iiwu_sample_t *sample):
- ensure refcount == 0 or return FALSE (not free'd)
- call SF loader->sample_free method
- return result of calling sample_free method
I guess the critical part is ensuring that there isn't a race between
free-ing a sample and it getting used again. Does this sound like the
right way to do things? Any suggestions?
I'll grab CVS and see if things break :) Cheers.
Josh Green