[Top][All Lists]

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

Re: [fluid-dev] Questions about Gleam

From: Miguel Lobo
Subject: Re: [fluid-dev] Questions about Gleam
Date: Tue, 22 Apr 2008 20:02:58 +0100

Using pools of preallocated objects is indeed one classical solution to the problem of having to allocate and de-allocate many objects quickly.  However, there are some tradeoffs that need to be made and at this point I think it's best to give the application writer the flexibility to implement a solution as simple or complex as it needs.  Especially since there is no real need for the synth to do any event allocation or de-allocation.

About using listeners/callbacks, one thing I want to avoid is calling application code from the synthesis thread.  This thread is very time-critical and will typically run with elevated scheduling priority, and shouldn't really be doing anything but synthesis.  The condition sync event is easy to use and, because the wait and subsequent processing happens in another thread, has much fewer chances of interfering with synthesis timing.


Check out Gleam, an LGPL sound synthesizer library, at http://gleamsynth.sf.net

On Tue, Apr 22, 2008 at 6:20 PM, jimmy <address@hidden> wrote:
On Mon, Apr 21, 2008 at 3:08 PM, Miguel Lobo
<address@hidden> wrote:
> Events can be generated and consumed at quite a high
rate, so event
> management can be critical for performance and
especially latency.
> Applications might implement different solutions to
deal with this,
 so I
> wanted to keep GleamCore flexible in this area.  In
fact, the
> parts of GleamCore don't do any allocation or
de-allocation of
 events; the
> MIDI converter does, but it's just meant to be a
helper to deal with
> data and its use by the application is completely
optional.  Perhaps
> should be moved out of GleamCore, as nothing in
GleamCore depends on


That sounds good.

> Another general target is to avoid any calls to
memory allocation
> (which have potentially unbounded duration) in the
synthesis thread.
 At the
> moment we're still quite far from that target, but
the freeing of
 events is
> the most important place, I think, where this idea
impacts design
> than just implementation, so I wanted to try to get
it right as early
> possible.

Let me just share some design consideration, or just
call it experiments to try to see if it helps.  For
event objects, you can try to have a collections of
some sort to hold on to pre-allocated events.  The
events are either allocated as needed, or
pre-allocated at start-up (and have command-line
option for the initial size of the collection).  When
you need an event, remove it from the collection, then
use it just as it has just been allocated.  When you
are done with the event, throw it over to a separate
thread to do any cleanup/re-initialize and add it back
to the collection of pre-allocated events.  You can
even have that secondary thread to check occasionally
if the collection is running low on pre-allocated
events, if it is, then create some new events for that
collection.  Don't know what kind of impact that may
cause, but just an idea.  There could be a threshold
that if there are way too many events in that
collection, some of the could be freed and
deallocated, too.

That way, the events are already pre-alocated, just
need to set the states of the internal variables and
not worry about time for memory allocation.

I used these techniques in Java for potential
CPU-spikes and overhead in garbage collection for
excessive allocation/deallocation of objects.

> Virtual functions have a cost both in compile-time
optimization and
> performance and should be avoided in time-critical
code whenever
> Events could have a virtual callback to notify of
their consumption,
> that would be quite expensive.  The intended way to
know when a point
> been reached in the event queue is the condition
sync event, which
> minimal cost for the synthesis thread.  An example
of its usage its
> in playmidi.cpp:
>     /* add a condition sync event so we know when
all events have
> played */
>     GleamConditionSyncEvent&
>     endEvent.freeList = &freedEvents;
>      endEvent.time = lastTime;
> [...]
>     /* wait until the end event is played */
>     endEvent.conditionSync.wait();
> Hope these answers some of your questions.
> Regards,
> Miguel

I haven't done much with C++ for a while.  But in
Java, there are events, and event listeners.  Where
you could add some object that implements the
event-listener interface (basically a callback
function) intered in some particular event(s).  When
the event is fired, each and every one of the
event-listeners already registered are notified
(called-back).  There might even be a property
(variable accessible via getter/seter functions) for
veto-ing some proposed action like exit the program if
it can't save the current settings...

Of course, we may have to be careful for realtime
events.  But this particular event isn't quite


Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

reply via email to

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