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

[Reinhold Hoffmann]

Thanks for the proposal.

Let me add my two cents. Memory usage is not only an issue on embedded
systems but also for operating systems like Windows. People simply load
soundfonts no matter how big they are. The Musyng Kite old soundfont is a
very good example. In these days soundfonts of up to the size of 1GB are
real. In our app we had to implement a scenario to temporarily unload/reload
soundfont when a larger memory portion is temporarily required for another
specific action of the app. On the other side the beauty of having all sound
samples in one file is that the user does to need to take care of a
dedicated soundfont loading e.g. a soundfont for a certain music instrument.
However, in most cases only a very small portion of a huge soundfont is
really used.

I support having a solution as proposed here but it is important to find a
way for scanning and loading of the soundfont not at the expense of the CPU
usage for the app e.g. in the background.

Reinhold 

PS: Instead of using the word "lazy" I would vote for the word "smart" :-)

-----Ursprüngliche Nachricht-----
Von: fluid-dev [mailto:address@hidden
Im Auftrag von Tom M.
Gesendet: Dienstag, 3. April 2018 21:13
An: Marcus Weseloh
Cc: address@hidden
Betreff: Re: [fluid-dev] Proposal for a new feature: lazy-loading of
SoundFonts

So briefly, your main motivation for this feature is memory usage.
Absolutely comprehensible on an embedded system. You therefore want to parse
only "high-level preset information" of a SF file. I'm missing information
about SF2 Instruments here.

Counterproposal: Instead of lazy-loading structural information of a SF2,
continue to parse all its structural information (i.e. preset, instruments,
samples), BUT postpone the loading of the SDTA chunk. In fact, the biggest
soundfont I have around is the "Musyng Kite original, old version". It's
file size is 1 747 075 246 Bytes (==1.6 GiB). It's SDTA chunk alone is 1 746
365 570 Bytes in size. The rest, i.e. 1747075246 - 1746365570 = 709676
Bytes, is structural information. Do you really want to start optimizing the
loading and parsing of those 700 KiB? With solely lazy-loading the SDTA
chunk we would get rid of drawback no. 1. And if parsing all those
structural information is yet too slow, we can still think about how to make
it faster.

Speaking of lazy loading the SDTA chunk: Wouldnt a memory mapped file
perfectly fit this use-case? Instead of letting the sample data point to
RAM, just make them point to the mem mapped file? Not sure what an impact
mem mapped sample data would have on real-time rendered audio though...

I do believe that this lazy-loading feature in general could also be useful
for MIDI file playback, specifically for hiding latency prior playback
start. Leading to drawback 2: Who is that mysterious separate thread? A
thread that will be spawned on every fluid_synth_program_change()? In case
of MIDI file playback it could just be the rendering thread? Not sure.


Tom

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