[linux-audio-dev] Re: audio application design problem

[Juhana Sadeharju]

>From: Christian Henz <chrhenz at gmx.de>
>
>So far I've been using an Observer pattern

Are all these patterns described somewhere in the web?
People refers mostly to some book(s) but that is not
available for me.

>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.

The audio thread should not execute even indirectly any GUI code.
If you send commands from audio thread to GUI thread, the GUI
thread should not execute each command "as is". If the audio thread
sends commands at too fast rate and GUI thread processes each of them,
the system breaks. So, the de-coupling must happen at greater level
than at basic threading level.

I would set up the graphics engine to run at constant frame rate;
say, 30 frames per second which is enough for our eyes. Then I would
set the audio thread to send events at most at rate 30 times per
second. GUI thread should process as many events at a time as possible.
In practise, the fixed frame rate would be an upper bound for the
actual rate; rate could be 10 Hz if there is a lot of drawing --- that
is why the events must be processes in "as many as available" manner
and some multiple events may require skipping.

In simplest, the fixed rate GUI could peek at the variables of
the audio thread; no FIFO.

Using any frame rate bound in non-video-player applications is something
I have not seen before. I use this kind of fixed frame rate in my little
experimental painting software. E.g., GIMP don't work that way.

 -*-

How Ardour and other realtime applications do it? What if one uses
a volume meter plugin with small buffer size? Would the plugin
be executed, e.g., 200 times per second and at each time would GUI
be changed? Not a good idea. Has this problem dealt in GMPI
discussions?

Regards,
Juhana