Subject: Re: [linux-audio-dev] A "best" event delegation strategy?
From: Paul Davis (paul_AT_linuxaudiosystems.com)
Date: Fri May 30 2003 - 16:00:59 EEST
>I am trying to implement a (hopefully:-) ) simple general-purpose event
>delegation architecture.
>The actual application will propably be something like a network of
>modules that can do arbitrary filtering, generation and manipulation of
>midi events in real time.
>
>As propably different kinds of external event sources, like several midi
>ports, maybe joystick device and of course a gui, are involved, how
>would one efficiently organize the delegation of events passed between
>the modules, so that the everything is still thread-safe?
>
>The three main ideas i can currently think of are:
interesting you should ask. in ardour, i have recently been shifting
from a rather complex model toward a very simple one. ardour has
several event sources (automation, GUI, MIDI, audio). there used to be
two different approaches to processing an event:
a) code to handle it is part of an object, and can be called
by any thread.
b) code to handle it is part of an object, but must be called
by a specific thread.
events in class (b) would be queued (lock-free) where they would wait
to be processed by the relevant thread. events in class (a) would get
handled immediately by whichever thread received/noticed the event.
slowly, but with all the certainty of a rising tide, everything is
shifting to a model in which more and more events are queued (lock
free) for the main audio thread, and all events are processed in FIFO
order by that thread.
the complications that i've discovered from attempting to have
different threads handle things without using locks are just to
signficant to be worth the effort (at least at this point).
in addition, lots of event processing in ardour consists of setting a
"desired" value for various things; the real-time code is responsible
for interpolating between the current value and the "desired"
value. you can imagine, i trust, that this can get quite complicated :)
--p
This archive was generated by hypermail 2b28 : Fri May 30 2003 - 16:00:47 EEST