On Wednesday 14 April 2004 10.45, Robert Jonsson wrote: [...] Well, there's always the point-point connection variant; using 1394, ethernet or whatever as high speed serial ports, rather than bus interfaces. You can use ethernet interfaces and crossover cables, for example. No hubs or switches, no collisions or anything. That said, I don't know which is better in terms of hardware and drivers; 1394 or ethernet... AFAIK, both are essentially high speed serial bus interfaces, but it might be that 1394 doesn't have collision detection h/w and stuff like that. Don't know if it's a real master/slave system on the h/w level. Ethernet is not... With P-P connections only, it's irrelevant, as long as you can keep any such logic out of the way. //David Olofson - Programmer, Composer, Open Source Advocate .- Audiality -----------------------------------------------. | Free/Open Source audio engine for games and multimedia. | | MIDI, modular synthesis, real time effects, scripting,... | `-----------------------------------> http://audiality.org -' --- http://olofson.net --- http://www.reologica.se ---

On Wednesday 14 April 2004 09.47, Anders Torger wrote: [...] Sounds like you'll need something like this: * A real time operating system * Decent ethernet hardware (most 100+ Mbit h/w should do) * A protocol stack with RT streaming support. (Or implement your own protocol, using the ethernet h/w as high speed serial ports/bus interfaces. * A distributed hard RT application The ethernet hardware won't be a problem. We're talking µs latencies on decent cards, so it's all about the software, including the OS, the drivers, the protocol stack and your application. However, since you have a roundtrip latency (master->nodes->master), you get much more sensitive to scheduling jitter than an ordinary RT audio system. Unless the scheduling jitter is practically zero, the network connections have to be handled like streaming audio connections; ie the same as if you were using audio interfaces for the master/node streaming. (Right; the NICs transfer data faster than audio interfaces locked at audio rate streaming, but that only affects the fixed/minimum latency. If you send data too late, someone will still miss a deadline; either you, or the receiver on the other node.) Some people have been doing this sort of stuff with RTLinux and/or RTAI. Maybe you should ask on the respective lists. (I'm not up to date...) Note that these days, both RTL and RTAI let you run hard RT code in user space (pretty much like the SCHED_FIFO threads we're using for "normal" user space RT), so you don't *have* to split your RT code off into kernel modules. If you're using lock-free sync constructs, porting an app with SCHED_FIFO audio threads should be trivial. If you use OS provided sync constructs, you'll probably have to replace those with RTL/RTAI equivalents. Some URLs: http://sourceforge.net/projects/rtnet/ http://www.ecsl.cs.sunysb.edu/rether/ http://www.fsmlabs.com/products/lnet/ //David Olofson - Programmer, Composer, Open Source Advocate .- Audiality -----------------------------------------------. | Free/Open Source audio engine for games and multimedia. | | MIDI, modular synthesis, real time effects, scripting,... | `-----------------------------------> http://audiality.org -' --- http://olofson.net --- http://www.reologica.se ---

Hi, Interesting project... Most of the protocols (RTP and others) that have been mentionned in the replies are on top of TCP or UDP and thus are not adapted for your real time application. Either ethernet or 1394 would be more adapted. IIUC, you don't need some kind of load balancing between the machines, i.e. the applications will be assigned statically on the different nodes without any dynamic job creation/deletion? fd Le mer 14/04/2004 à 09:47, Anders Torger a écrit :