Re: [fluid-dev] Questions about Gleam

[Guillaume Pothier]

> 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.

Completely agree with you on the flexibility point.

> 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.

Ok, I understand that concern very well, but I think it is the
responsibility of the application writer to ensure that his callbacks
execute quickly. There could be a default callback that simply add the
events to a list, but I think (sorry for insisting that much...) that
it would be a good thing to give the programmer the flexibility to do
some other processing with consumed events, if adding them to a list
and processing them in a separated thread is non optimal in his
application (which is my case).
Also note that if the synthesis thread has a high priority (which I
think is a good thing), it has the potential to starve the auxiliary
threads that do the feeding/cleanup.

Regards,
g

>
>
> Regards.
>
> --
> Miguel
> 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
> >  memory
> > > 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
> >  non-optional
> > > 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
> >  MIDI
> > > data and its use by the application is completely
> > optional.  Perhaps
> >  it
> > > should be moved out of GleamCore, as nothing in
> > GleamCore depends on
> >  it.
> >
> > Miguel,
> >
> > That sounds good.
> >
> >
> >
> >
> > > Another general target is to avoid any calls to
> > memory allocation
> >  functions
> > > (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
> >  rather
> > > than just implementation, so I wanted to try to get
> > it right as early
> >  as
> > > 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
> >  run-time
> > > performance and should be avoided in time-critical
> > code whenever
> >  reasonable.
> > > Events could have a virtual callback to notify of
> > their consumption,
> >  but
> > > that would be quite expensive.  The intended way to
> > know when a point
> >  has
> > > been reached in the event queue is the condition
> > sync event, which
> >  has
> > > minimal cost for the synthesis thread.  An example
> > of its usage its
> >  provided
> > > in playmidi.cpp:
> > >
> > >
> > >     /* add a condition sync event so we know when
> > all events have
> >  been
> > > played */
> > >     GleamConditionSyncEvent&
> > >
> > endEvent(events.addType<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
> > realtime-sensitive.
> >
> > Jimmy
> >
> >
> >
> >
> >
> ____________________________________________________________________________________
> > Be a better friend, newshound, and
> > know-it-all with Yahoo! Mobile.  Try it now.
> http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
> >
>
>
> _______________________________________________
>  fluid-dev mailing list
>  address@hidden
>  http://lists.nongnu.org/mailman/listinfo/fluid-dev
>
>