Re: [fluid-dev] Possible approach to preloading samples / presets

[Marcus Weseloh]

Hm, looking at the code and thinking about this some more...

You suggested something like
  fluid_synth_pin_preset(synth, fluid_preset_t*)

The problem here is the fluid_preset_t pointer. Exposing a public API
that consumes fluid_preset_t pointers will introduce some problems, as
there is no thread-safe way of retrieving and using those pointers for
external applications (outside of the synthesis thread) and without
implementing a separate Soundfont loader.

What do you think about:
fluid_synth_pin_preset(synth, sfont_id, bank, program)
fluid_synth_unpin_preset(synth, sfont_id, bank, program)

Cheers
Marcus

Am So., 25. Okt. 2020 um 11:34 Uhr schrieb Tom M. via fluid-dev
<fluid-dev@nongnu.org>:
>
> Ok, I see.
>
> So, my preference of implementing this is to use the pinning approach.
>
> I'm thinking of a function like
>
> fluid_synth_pin_preset(synth, fluid_preset_t*)
>
> The function will attempt to pin all samples of the given preset and
> load them into memory, if they are currently unloaded. "to pin" in this
> context means preventing them from being unloaded by an upcoming channel
> prog change. If successful, FLUID_OK is returned.
>
> If the preset doesn't support pinning (because it's a DLS preset, which
> doesn't use the sample cache currently), FLUID_FAILED is returned.
>
> If the preset supports pinning, but dynamic-sample-loading is disabled,
> FLUID_OK is still returned. Not an error, it is already loaded and will
> never be unloaded.
>
> No exposing of the internal sample cache is needed.
>
> Ofc, we'll need a way to unpin presets. I'd vote for a separate "unpin"
> function. This function should unset the is_pinned flag. Again, if the
> preset doesn't support pinning, FLUID_FAILED is returned. Ideally, the
> function also unloads the samples if the given preset is no longer
> referenced by any channel. In this case, care must be taken to avoid a
> race condition with the rendering thread: If you unload the samples from
> memory (because the ref count was zero) and just right afterwards, the
> rendering thread selects the sample again, then just make sure that the
> sample is first being unloaded cleanly and then loaded back cleanly.
> Can't remember if you were already using some kind of synchronization
> like that, didn't had a look.
>
> Thoughts?
>
>
> Tom
>
> _______________________________________________
> fluid-dev mailing list
> fluid-dev@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/fluid-dev