Re: [LAD] pyqt vs wxpython for audio apps?

On Sun, Sep 6, 2009 at 2:38 PM, Iain Duncan<iainduncan(a)telus.net> wrote: why would it do that? most of what happens in the GUI as far as a display is driven by timers, since the screen update rate is relatively low. there is no point, for example, trying to display peak meters at "audio rate" - this is hundreds of times faster than the screen refresh. similarly for waveform displays (e.g. oscilloscopes). the data is flowing by at a much faster rate than the screen can display it, so you pick an update based mostly on the screen, not what is happening in the data. in an ideal world, GUI's would be driven by the video interface's "sync to vblank" signal, in the same way that we drive audio via the interrupt from the audio interface. without openGL, this concept doesn't exist, alas. for specific notifications between the audio engine and GUI, you will want some kind of (relatively) lock free communication method. there are a variety of ways to do this, some better than others. ardour currently tends to use a FIFO sometimes read from a timeout in the GUI, and sometimes coupled to a pthread_cond_t (in this latter case, the audio engine will signal the GUI that something has happened). this latter technique technically violates RT programming guidelines because to raise a condition variable (pthread_cond_t) you need to take a lock. however, contention on the lock is almost non-existent and so for practical purposes it ends up not being an issue. you can also register callbacks with the engine to be called when things happen there - the callback must be realtime safe, but can queue up some kind of further action in the GUI that it knows will be "picked up" in the "near future".