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

Jens M Andreasen wrote:
> Looking at your screenshot and reading the labels I wonder why the UI is
> so concerned about what jack is doing. I would have thought jack_run
> will do whatever the UI appears like, no? The exception being time
> information/sample count needed to update blinking-lights and
> measure-count.
>
>
> g_timeout_add ( 50,
> my_time_function,
> (void*)some_data );

Yeah, that's what I'm using for the blinking lights.

> For pressing buttons I see no reason why you should not just go ahead
> and update the structure that jack_run can see. Assuming this is a
> simple integer update.

Right, for pressing beats buttons, there's no need to lock anything.

> Say you need to load files, malloc and whatnot for a new track. Fine, do
> all that first and then let jack_run insert the new track into the main
> structure before doing the actual run.
>
> if(p){ // we have a new track to insert
> ...
> p = NULL; // notify it is done
> }
>
> if(q){ // we should delete one track
> ...
> q = NULL;
> }
>
> // start of jack_run
> ...

You quite simplify things (you can add tracks but also increase beats number,
etc...) but you're not so far of what I actually do. The point is that right
after calling sequence_resize() (which does a similar thing to what you
describe), the gui automatically refreshes itself (redrawing all of the tracks)
and for this purpose queries the sequence to know what it has do draw.

But "right after" resizing the sequence, the jack thread is likely no to have
yet received messages and updated the actual sequence data so that the gui is
going to read out-of-date or in-the-process-of-getting-updated informations
about tracks.

This is where my shadow would play its role. By getting updated "right after" a
such (currently locking) function as sequence_rezize(), the gui could read from
the sequence very fast. This shadow is somehow fake : it has no consequence on
the sound, it is here to simulate zero-latency so that the gui can run as fast
as it wants. The "real" sequence data would then get transparently updated in
the background, by the jack thread.

I'm now starting to think that this shadow should be part of the gui data. So
that the gui update itself directly, signalling the sequence to change but never
querying the sequence to know what actually happens underground. The gui would
be more self-contained.

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

--
   og