[LAD] pyqt vs wxpython for audio apps?

Paul Davis paul at linuxaudiosystems.com
Sun Sep 6 21:36:27 UTC 2009


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



More information about the Linux-audio-dev mailing list