> One way to use NICs would be to drop the protocol stack and just use > the NICs as high speed serial interfaces. You could use cross-over > cables and point-point connections only, to completely avoid the risk > of collisions and the related "random" latencies that may cause.
right, i remember reading about a specialized yet simple-to-construct form of network hardware developed at purdue university that allowed latency in the microseconds for certain types of distributed apps. they use it to cluster linux boxes though, not rt os's. > > >> Naturally this >> depends on a signal path separable into big chunks. > > Yes... Or rather, the number of node->node hops is restricted by the > connection latency, internal latency of nodes and the required total > system latency. Use RTL or RTAI, fast NICs, cross-over point-point > connections and process say, 0.1 ms' worth of audio/MIDI data at a > time, and you can send data around quite a bit before you even reach > the "magical" 3 ms. Unfortunately, processing that small chunks of > data isn't terribly efficient, so at some point you'll undo the > advantage of having more CPU power available. > What i was thinking of only involves sending MIDI over the network, audio produced by each machine would go directly to a mixing board and not back into a computer. The point would be to perform musical pieces involving many synth (or sampled) parts by breaking the number crunching down into parallel sections simple enough to be handled by a single machine. For example, if nine synths are playing concurrently, put 3 on each of 3 machines. Setup & teardown of the signal paths can happen in non-rt, but the midi notes need rt delivery. --jacob
