Re: [fluid-dev] Proposal for a new feature: lazy-loading of SoundFonts

[Marcus Weseloh]

Hi JJC,

I don't think the audio rendering uses the same mutex, otherwise you would get audio dropouts if you were loading a large soundfont while sound is being played. The API gets locked, so you can't add any more notes or change the sound, but already started notes carry on playing. Or am I missing something?

Cheers,

Marcus

Ps: sorry for top posting, am on they move.

Ceresa Jean-Jacques <address@hidden> schrieb am Fr., 6. Apr. 2018, 15:41:

Hi,

 

>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 for simplicity):

- 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 fluidsynth structure.

cheers.

jjc

 

 

 

> Message du 05/04/18 20:05
> De : "Marcus Weseloh" <address@hidden>
> A : "FluidSynth mailing list" <address@hidden>
> Copie à :
> Objet : Re: [fluid-dev] Proposal for a new feature: lazy-loading of SoundFonts
>
>

Hi all,

>

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?

>

Cheers,

>

    Marcus

_______________________________________________
fluid-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev

_______________________________________________
fluid-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev