fluid-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] Thread safety long-term thoughts


From: jimmy
Subject: Re: [fluid-dev] Thread safety long-term thoughts
Date: Mon, 16 Nov 2009 07:02:42 -0800 (PST)

> Date: Mon, 16 Nov 2009 00:37:40 -0800
> From: address@hidden
> 
> Quoting David Henningsson <address@hidden>:
> 
> > 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








reply via email to

[Prev in Thread] Current Thread [Next in Thread]