[LAD] pyqt vs wxpython for audio apps?

[Iain Duncan]

On Sun, 2009-09-06 at 17:36 -0400, Paul Davis wrote:
> On Sun, Sep 6, 2009 at 2:38 PM, Iain Duncan<iainduncan at telus.net> wrote:
> >> Paul Davis wrote:
> >> > my recommendation is that you rethink whatever architecture you're
> >> > imagining. you will not, and almost certainly should not, drive a GUI
> >> > event loop from anything audio related. you should (IMHO) be thinkng
> >> > about two different loops: a GUI event loop driven by mouse, keyboard
> >> > and system time(r|out) events, and an audio engine loop driven by the
> >> > "clock" of the audio API (JACK, ALSA, whatever). the GUI doesn't need
> >> > tight timing (remember that your display almost certainly only
> >> > refreshes at no more than 100 times per second, and quite possibly
> >> > more in the range  of 60-80 times per second.
> >
> > Thanks. How do you communicate to the gui loop when it should update
> > itself based on audio activity?
> 
> 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".

Thanks Paul, that should give me lots to think about. =)
iain