[linux-audio-dev] Re: Audio over Ethernet

John Lazzaro lazzaro at eecs.berkeley.edu
Wed Apr 14 20:27:44 UTC 2004

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:


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:


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
lazzaro [at] cs [dot] berkeley [dot] edu

More information about the Linux-audio-dev mailing list