> 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 -- tim@xxxxxxxxxx http://tim.klingt.org Just what the hell is the experimental tradition? Morton Feldman
Attachment:
signature.asc
Description: OpenPGP digital signature