I think I may have an idea about how to do this even. I'll take a look
at scsynth later today and see if my hunch is correct. My guess is,
somewhere the audio thread is added... I wonder if the answer may be
an OSC message to create a second audio thread on the same server, and
if this is possible? The 'second thread' would be the second group
node that James is talking about. Shares memory and busses with the
first one, but the two thread's synths can't reliably feed into each
other?
Not even sure of this is how it all works. I'll try to take a look
later.
some of this code may be of some help:
http://tim.klingt.org/git?p=nova-server.git;a=tree;f=source/server;hb=HEAD
a brief explanation about my architecture:
- a dsp_threads class, manages a group of realtime helper threads
- a dsp_thread_queue class, which is a schedulable representation of the
dsp graph with an activation count to determine `runnable' nodes
- a dsp_queue_interpreter, called by the dsp threads, interpreting a
dsp_thread_queue
waking the helper threads is an operation involving quite some latency,
the worst cast scheduling latency of osx is about 300us, of a real-time
patched linux about 20us. so once running, the threads should not be
suspended before the end of the dsp tick. unfortunately, this will
result in some busy waiting, if the threads cannot be used in parallel
for the whole time ...
concerning OpenMP, i would be curious, if it is feasible to use it in a
low-latency soft-realtime system ... e.g. does it use blocking
synchronization?
tim