Re: [fluid-dev] A question of memory

[Josh Green]

Sounds like pretty good arguments/information to me.  I think it might
be better to implement streaming support though, which has been on the
wish list for a while.  I agree it is a bit overkill to lock all sample
data, as it currently is, when possibly only a few are being actually
used for the active presets.

Swami loads instruments into FluidSynth in an on demand fashion (when
the preset is requested), but no mlock or any other precautions are
taken at this point.  I've been kicking around the idea of forking
FluidSynth and making a version which uses libInstPatch, and adding
support for other formats natively into FluidSynth.  At this point there
is initial bare minimum support (as in no effect parameters yet) for DLS
and GigaSampler using Swami.  The other option is just continue to use
libInstPatch/Swami as a wrapper for FluidSynth (as it is now).  Peter
Hanappe, the original author, went to great lengths to keep FluidSynth
non-dependent on other libraries.  I think it is good to keep FluidSynth
as portable as possible, but I'm not attached to keeping it to where it
has no dependencies, especially when it makes life easier and adds
additional functionality.  I'm still undecided on this.  I was just
trying to think what the future holds for FluidSynth, and it seems right
now the code base is a bit dusty and there is a lot of utility/system
compatibility stuff that could be handled by a library such as glib.
And when I was looking over the SoundFont loading code (the remnants of
stuff I wrote over 6 years ago in Smurf SoundFont Editor, which was
"hacked" into FluidSynth), I started to think, this really needs an
overhaul.

One thing that keeps me from doing this, is the thought of more work ;)
Swami is only 1 man power at this point (me) and could really use more
developers.  FluidSynth consists of about 1/4 man power (me and the
occasional patches submitted by others, which is great!) and really
could use some more developers.  The thought of merging the two to some
extent, or at least leveraging off each other, is appealing.

Any thoughts?

        Josh

On Tue, 2006-11-28 at 07:52 -0700, Dave Serls wrote:
> 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?
>