On Sun, 2009-09-06 at 17:36 -0400, Paul Davis wrote: > On Sun, Sep 6, 2009 at 2:38 PM, Iain Duncan<[email protected]> 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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
