> Date: Mon, 16 Nov 2009 00:37:40 -0800 > From: [email protected] > > Quoting David Henningsson <[email protected]>: > > > However, nothing new without a downside. Since the > sample is used by > > the voice renderer, freeing a preset or soundfont is > not solved easily. > > But outlined, first we should check if there is an > audio thread > > running, if there isn't (embedded case, fast-render), > we can just go > > ahead. Otherwise send a voice event saying we should > kill active voices > > referencing the preset or soundfont. We then block the > call until the > > audio thread has processed our message (simplest). > Optionally we could > > return asynchronously, but then we still need some > kind of garbage > > queue. > > > I think reference counting would help a lot with > this. When a voice > is using a sample, it holds a reference. The sample > references its > parent SoundFont, etc. This is how libInstPatch > works. If a > SoundFont gets removed or changed, different presets get > assigned, > causing the samples to become unreferenced, ultimately > freeing the > SoundFont if no more references are held. >
Don't know how practical this is, but just some more ideas for the discussion. Often in MIDI, the same type of data is used time and again as the verses repeat. Depends on resources available. If the system have plenty of resources available, Fluidsynth could probably move the unreferenced presets into a cache, probably with some last-used timestamp. Don't know if the time to look up a preset in the cache again may be any faster or slower than allocating new preset, or may add an overhead to a preset that doesn't already in the cache. The cache may have its own expiration purge cycle periodically, depends on system resources, or user configurable options. For extreme scenario example, some presets may be used again within 5-10 minutes, or even 15-20 minutes for a fairly long song. But for a movie-like environment, or studio-session, should the cache keep presets longer than 30 minutes? Or the cache is so large that looking up a preset takes longer than allocating a new preset, then it becomes counter productive. Jimmy _______________________________________________ fluid-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/fluid-dev
