iiwusynth-devel
[Top][All Lists]
Advanced

[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





reply via email to

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