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

[Tom M.]

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