>Does anybody see a drawback in doing the lazy sample loading in-thread under
>the API lock?
Yes actually the potential drawback exists seriously and i understand your
fears but fortunately the actual inner fluidsynth structure make things easy to
solve this (i guess :), unless i have missed something :().
As far i remember actually in Fluidsynth, the whole API set could be see mainly
in functionnal and independant groups (the discussion is limited to 3 groups
- the soundfont API group. Each function accesses the same inner soundfont data
structures ( mutex protected in case of multi-task simultaneous calls).
- the MIDI API group. Each function accesses the same inner data synth instance
structure (also mutex protected in case of multi-task calls).
- the audio rendering API group. Each function accesses the same inner data
rvoices structure (also mutex protected in case of multi-task call).
Actually all 3 API groups make use of the same (a single) mutex (i guess i am
not wrong!) and this is not a good as the execution of one API group (i.e
soundfont) can lock an audio rendering API
this could result in an audio rendering API waiting until this "lazy" sounfont
API have finished (in other words the audio rendering API became "lazy").
Note that this case of unwanted real time dependency, is not predictible (i.e
behave differently if the audio rendering API is called at "interrupt time" or
called by a separate audio task).
As far the data structure of each group are independant, they should be
"multi-task" protected by an independant mutex API. This will solve the
dependency issue described above.
I guess that Tom should confirm or not this assumption about the actual inner
> Message du 05/04/18 20:05
> De : "Marcus Weseloh"
> A : "FluidSynth mailing list"
> Copie à :
> Objet : Re: [fluid-dev] Proposal for a new feature: lazy-loading of SoundFonts
thank you very much for your feedback! Good to know that there is interest for
this feature outside of my particular use-case.
I've decided to go the route Tom suggested: concentrating on the samples first
and leaving the "structural" information loading unchanged for now. That will
bring the most immediate benefit. And if the structural information loading is
still a problem, we can tackle that another way.
I have already implemented a test version of this lazy (or smart :-) sample
loading by simply doing it when a preset is selected from a Soundfont via
fluid_sfont_t::get_preset. That obviously has the drawback that the Fluidsynth
API stays locked during loading, but leads to an extremely simple
implementation. The audio rendering code doesn't seem to acquire any API locks,
so there shouldn't be any audio dropouts due to the API lock being held for too
long. And I just noticed: Soundfont loading is currently done under the API
lock as well! So there's no need for an additional thread, it seems.
Does anybody see a drawback in doing the lazy sample loading in-thread under
the API lock?
fluid-dev mailing list
fluid-dev mailing list