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
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/fluid-dev
