[linux-audio-dev] Lock-free gtk/jack interaction

Olivier Guilyardi ml at xung.org
Mon Mar 14 16:34:34 UTC 2005


Jens M Andreasen wrote:

> Isn't the GUI already a kind of "shadow data"?
> 
>     gtk_toggle_button_get_active ()
>     --------------------------------
>       Returns TRUE if the toggle button is pressed in
>       and FALSE if it is raised.
> 

Indeed. You exactly got what I mean. It then becomes more a design issue : the 
gui, based on gtk, is "shadow-capable" but I'm not using this ability.

Additionally, redesigning things so that the gui properly "shadows" the sequence 
would oblige me to heavily optimize things. When adding a single track I 
currently destroy the whole workspace and query the sequence to so that the gui 
can redraw the whole thing, recreating all widgets.

By redesigning the gui, I would keep many widgets as they are and only create 
some new ones, or destroy a few... This is very important, when you have a big 
workspace (ie: 1k beats, 16 tracks), because things then get very slow the way I 
currently do.

I did think about this, but it required coding a lot of small functions for a 
variety specialized routines, and I would also need to change the way files get 
loaded (this last point is the main reason why I wanted to put the shadow within 
the sequence itself). Anyway, although it requires some work, I think this is 
the way to go.

>>Or the gui could get notified by the sequence as Paul explains.

I hesitate here : would a such sequence-to-gui notification design be more 
souple/maintainable than a "shadowing" gui, for future, unplaned features ?

I guess the two paradigms could coexist, if I ever need the RT thread to send 
signals to the gui...

> I also think you can relax your speed expectations slightly. With jack
> running say 64 samples each time around, it will have done its thing 10
> times before the next monitor refresh.

My jackd manpage states that the default frames/period setting is 1024, which 
means that for a frame rate of 44100 Hz, I'm around 44 periods by second, which 
is less than a monitor refresh. And what if some user needs to set that up to 
4096 frames/period or more ?

--
   og



More information about the Linux-audio-dev mailing list