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. 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 <[EMAIL PROTECTED]> wrote: > On Mon, Apr 21, 2008 at 3:08 PM, Miguel Lobo > <[EMAIL PROTECTED]> 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 [email protected] http://lists.nongnu.org/mailman/listinfo/fluid-dev
