Re: [fluid-dev] A question of memory

[Dave Serls]

I've been having an enlightening offline discussion with P. Millar about
memory usage within fluidsynth, particularly the 'mlocking' of soundfont
sample data areas.  I've done some cursory exploration of the source code
and come to the conclusion that the hypothetical average user (of which there
are none for fluidsynth) can only be hurt by the current scheme.  Certainly,
any user who uses one or more large General Midi soundfonts will be at a
disadvantage.  

The only memory that is locked is the sample data for each soundfont.
The channel, preset, sample, voice, and audio buffer areas, although much 
smaller,
are not locked.  When the amount of locked sample storage becomes a significant 
percentage
of the real system memory, the likelihood of a paging event involving the other 
metadata
increases dramatically, followed by interrupted audio.

The simplest solution -- buy more memory, which is what I did.  Others may not
be able to do this.

A complex solution -- lock all the metadata when allocated, then lock the sample
data, generators, loops, headers for each program as it becomes an active 
channel,
similarly unlocking the previous preset occupant of the channel. 

There's also the potential issue of fluidsynth stack frames, and program pages 
causing
page faults. This could be handled by an early mlockall invocation.

Maybe that no one else has run into this problem, and I'm tilting at windmills?

-- 
************************************************************************
*   Dave Serls                                 Littleton, CO, USA      *
*   dashs.denver.co.us                         dashs.com               *
************************************************************************