Are all these patterns described somewhere in the web? People refers mostly to some book(s) but that is not available for me. 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