[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