Re: [iiwusynth-devel] Lates CVS changes

[Peter Hanappe]

Josh Green wrote:
> On Mon, 2002-12-02 at 10:34, Peter Hanappe wrote:
>
> > - 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? 

Currently not. It's not as easy as it may seem. Two issues:
- only the voice knows when it's finished playing. The voice knows
  it's sample but not the soundfont it belongs to. This could be
  changed.
- the voice is turned of in the DSP thread. Calling unknown code in
  the DSP lopp to handle sample management in a SoundFont is scarry.

Possible solution: the unload thread I added to unload an active
soundfont is quite easy and effective. It checks every 100 msec whether
the sfont has active samples and, if not, it's unloaded. Fairly clean
solution in my opinion.


> - 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

We could add a callback in the preset to tell it it has been selected.
We talked about it before, the risk exists that the synth misses noteon
events if the come directly after a program change message. And, you
can't do any file access in the preset->noteon function (for real-time
issues).


> - 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)

This is high on my todo list, but probably for FluidSynth 1.1 (not 1.0).
I have a first proposition ready below. Maybe there's
no need for on demand load and caching if streaming is available.

My basic idea for the streaming back-office is a cache
of sample buffers. These sample buffers store a part of the full sample 
and have the same size, for example 8k.
For a given SoundFont sample, the SoundFont starts by loading
buffer B[0], which contains the first 8k of the sample. The SoundFont
can then continue with preloading buffer B[1]. There should be an
overlap between buffer B[0] and B[1] to handle interpolation, minor time
delays, and short loops.
The SoundFont manages a buffer cache using as a hash key
the sample pointer and the buffer number and uses some kind of
heursitics to remove the old buffers (age, last time used, ...).

From a first analysis, I think we only need to add two variables
and one callback function in the iiwu_sample_t structure:

- unsigned int swap_mark: at what offset in the sample should the
  synth request to swap the buffers. Use 0 or UINT_MAX for 'static'
  samples.

- unsigned int offset: the offset in the sample of the current
  data pointer

- short* swap_buffer(sample, bufnum, &offset): returns the
  data pointer and sets the offset for buffer 'bufnum'.
  If the SoundFont can't handle the request immediately, i.e.
  it still has to load the buffer, it should return NULL. In that
  case the voice continues with the old buffer and tries again
  at the next DSP loop. That is why there should be some overlap
  between buffer B and buffer B+1


> 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?

Using a cache in combination with lock-free techniques, such as the
lock-free lifo/fifo developed by the GRAME team, should work okay.

Exciting, no?

Peter


> I'll grab CVS and see if things break :) Cheers.
>         Josh Green