> 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 <[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 > > _______________________________________________ fluid-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/fluid-dev
