12 Jan
2007
12 Jan
'07
5:21 a.m.
The skinny:
- Never make a blocking call in your synth thread; there are ways around it.
Using a thread lock is a blocking call.
- Use atomic operations where possible and for as long as possible to avoid
complicated messaging code.
- Have the synth thread operate on built-in types (int, float, bool)), which
can safely be set by any thread without worrying about locking.
- Use a timer in the gui thread to make a callback to update widgets based
on atomic values set by the synth thread. 20 ms is fine. Use a boolean to
indicate that a resource has changed and should be read.
This will get you through most problems. On the other hand, automating
controls (as is done in most plugin architectures like vst) is something
that needs to be event based from the synth thread to the ui thread, and you
will need to figure out a non-blocking message queue for that. For that I
leave the solution open to others in this list.
On 1/11/07, nick thomas <jesuswaffle(a)gmail.com> wrote:
I apologize if this has been discussed previously on the list; Google
didn't seem to be turning anything up from the list archives.
I'm writing my first DSP program for JACK. My problem is this: I've
got a high-priority audio synthesis thread, and a low-priority user
interface thread, and they need to communicate: the UI thread needs to
tell the synthesis thread to respond to the user twisting knobs and
moving sliders in the interface, and the the synthesis thread needs to
tell the UI thread what it's doing, so that the UI thread can update
its monitoring widgets. I'm sure that this is an extremely common
situation for JACK programs, and I was wondering how to handle it.
I know of two possible approaches: using locks and shared memory, or
using FIFOs and no shared memory. Vanilla pthreads provides direct
support for the former approach, and JACK's ringbuffer interface seems
to provide the necessary primitives to implement the latter approach.
A lock-based system would probably be substantially simpler to
implement than a lock-free one; however, I can imagine some possible
priority inversion issues with a lock-based system. I don't know if
that is ever a problem in practice, with real-time scheduling enabled.
Anyway, there's my question: which approach (lock-based or lock-free)
is generally favored for JACK programs? Thanks for helping a newbie
out!
--
Patrick Kidd Stinson
http://www.patrickkidd.com/
http://pkaudio.sourceforge.net/
http://pksampler.sourceforge.net/