[linux-audio-dev] audio application design problem

[Christian Henz]

Hi, as you may know I'm the author of simsam (http://simsam.sf.net) and I'm
a little stuck with some typical audio application design problems.

So far I've been using an Observer pattern to have the GUI updated as soon as
a parameter changes. Thus any operation setting a parameter can trigger one
or several Widgets to be redrawn. Since so far I only set parameters from the
GUI thread, the resulting GUI updates also run in the GUI thread, so no problem
there.

One problem however is that access to the parameters isn't synchronized and
therefore concurrency problems exist. The same problem exists between MIDI and 
audio thread, as MIDI events are currently handled entirely in the MIDI thread.
The obvious answer is to use mutexes to synchronize the parameters, but then 
of course they aren't rt-safe.

The next obvious answer would be to use a lock free FIFO. I've seen some code
passing MIDI events to an audio thread that way. Thus the state is only 
maintained in the audio thread. But what about GUI events? And GUI callbacks? 
Surely one doesn't want the audio thread to execute widget redraws. So one has 
to de-couple these mechanisms, for example by defining event and update 
messages and passing those around by FIFOs instead of direct parameter 
manipulation / direct GUI callbacks. Now this would totally break my app and I 
would therefore like to hear some thoughts on the whole issue before I start 
messing things up (even worse ;-P).


Thanks
Christian Henz