On Apr 14, 2004, Anders Torger wrote:
Thus, I think it is necessary to implement something operating on the ethernet level to get best performance in terms of throughput and latency.
/Anders Torger
If what you mean by "operating at the ethernet level" means "no Cobra-like hardware to help, but putting data directly into Etherframes w/o IP/RTP headers", then its unclear to me that working at the RTP/IP level is going to hurt you much. The simplest implementation would have RTP/IP header overhead, but there are nice header compression schemes that get rid of it:
http://www.ietf.org/rfc/rfc2508.txt
and its improved versions. By using RTP, you get a lot of protocol design you might otherwise need to do, within RTP (like RTP MIDI) and surrounding it (session management, etc).
One big thing you need to worry about are clocks -- unlike a protocol like AES/EBU or SPIDF, packet-based media is not sending an implicit clock along with the data. So, the nominal "sender sampling rate" can't be precisely linked to the nominal "receiver sampling rate" in a simple way. The consequence is either too much data piles up at the receiver, or not enough. One solution to this problem is to continuously running a sample-rate converter at the receiver in software, to keep the two sampling rates locked. See:
http://www1.ietf.org/mail-archive/working-groups/avt/current/ msg00569.html
and use the "Thead Next" to cycle through the discussion, it goes on a ways and lots of interesting folks drop in with info.
A separate issue for your "many streams" case is synchronizing the streams to each other, in the case where not all share the same nominal clock. RTP has tools for this, based on associating NTP timestamps from a common clock to each independent stream, that get used for audio/video lipsync, and can be repurposed here as well.
--- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu ---
