[linux-audio-dev] audio application design problem

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [linux-audio-dev] audio application design problem
From: Christian Henz (chrhenz_AT_gmx.de)
Date: Fri Apr 30 2004 - 14:55:18 EEST


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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Apr 30 2004 - 14:54:42 EEST