13 Mar
2005
13 Mar
'05
7:13 p.m.
In Jackbeat (written in C), I have the gui running in
one thread (the gtk main
loop) and jack in its thread. Currently, when tracks get updated, the main loo
p
sends a message to the jack thread, and then waits for an acknowledgement. I
currently use syscalls (message queues) for these messages, but that's not my
point (I'll turn that later into syscall-free fifos).
Waiting for an ack from the jack thread has a consequence : it locks the gui f
or
a brief moment, which seems to drive my spin buttons mad : when clicked they
will sometimes step the value by 1, sometimes 2, etc...
don't wait in the GUI. what you need to do is to hook a notification
mechanism from the RT thread into the main event loop of the
GUI. having the RT thread write a byte to a FIFO or raise/lower a
semaphore are the two best generally available ways of having it
notify the GUI that something has happened that it needs to know about.
many programs use this mechanism.
Message queues would still be used to let the jack
thread update itself the
"real" sequence. This is where would reside some latency : waiting for the jack
thread to get in sync. But the gui would never lock.
forget the idea of "sync". your GUI has no way to update more than
about 60-80 times a second anyway (because of the monitor refresh
frequency. your goal is to make sure that the GUI reflects the state
of the model/backend ASAP after the model/backend changes.
--p