Paul Davis wrote: > On Sat, Sep 5, 2009 at 5:33 PM, Iain Duncan<iainduncan(a)telus.net> wrote: >> Hi everyone, I'm wondering what most linux audio developers think about >> pyqt vs wxpy for writing audio app guis now that qt is gpl'd. >> Specifically I'm interested in tightly controlling the timing of event >> loop ( ie making some accurate external clock source like the csound >> engine be the time boss ) and making decent faders widgets. > > 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.

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

How do you communicate to the gui loop when it should update itself based on audio activity?

2009/9/6 Iain Duncan <iainduncan(a)telus.net> The folks at http://traverso-daw.org/ could definitely help you with PyQt.