Subject: Re: [linux-audio-dev] Distributed audio processing
From: John Lazzaro (lazzaro_AT_CS.Berkeley.EDU)
Date: Thu Oct 05 2000 - 01:10:55 EEST
> John, I'd like to have some more info: to use UDP which advantages has
> wrt TCP?
It comes down to the basic contract UDP makes with the user: send a
packet off to someone else and:
-- maybe it will never arrive
-- maybe it will arrive twice
-- if it does arrive, the whole packet gets delived as an
atomic thing to the app -- 1/2 of packet can't arrive, only 1 or 0
packet.
-- if it does arrive, the bits will all be right (this checksumming
functionality is what UDP delivers over sending just a raw IP
packet).
-- there's a certain "Maximum Transmission Unit" (MTU), which will
at least be 548 bytes, and which you can query the network to get
the real number, which is recommended for good network performance.
-- while there's no guarantee the endpoint sending the packet will
send it off right away, there's nothing in the specification that
specifies that a UDP packet be held at the host, and in practice
if you have a NIC hooked up to a local LAN with a good IP stack
the UDP packet will fly out the wire pretty quickly.
For many general-purpose apps, there's nothing to be gained by trying
to take advantage of UDP's characteristics as described above, just
a lot of hassle in dealing with the non-guarantees. These apps just
want a byte stream and care about fully utilizing available bandwidth,
and are (usually) insensitive to latencies at the start of large
data transfers. For these apps, TCP is just the ticket -- it makes a
network look like a reliable byte stream.
For some kind of media applications, especially interactive ones,
its pretty obvious how to take advantage of UDP's good points while
mitigating its bad points. Media data can be "packetized" into chunks
that map to the media itself -- frames of a video, lines of a video
frame, for example. For compressed audio, codecs often convert audio
input into compressed representation in integral frames -- 20ms of
audio maps into a 200 byte quantity, all 200 bytes of which you
need to start decoding (199 and you can't, but the 201'st byte won't
be helpful). Even uncompressed audio has this characteristic to some
degree, especially multi-channel sound with 24-bit or 32-bit words.
Basically, you
-- want to fill up the UDP packets to match the natural framing of
the media
-- depending on your application, you want to handle the fact that a
packet can get lost in different ways:
[1] For lower-latency apps, FEC works well -- one cool general-purpose
scheme described here:
http://www.ietf.org/rfc/rfc2733.txt
Sends along addition packets that are the exclusive OR of the
bits of the last two packets, so if one gets lost but the other
gets there you can XOR the FEC packet with the arrived packet to
get the lost packet.
[2] For higher latency, you may want to retransmit:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtprx-00.txt
[3] For some sorts of packets in some media apps, if they are going
to arrive late they aren't worth having at all, so you just use
techniques to make the best of the situation and save the bandwidth
of a retransmit that arrives too late.
Using RTP over UDP lets you do your own framing, and handle these sorts
of issues in an application-centric way. Use TCP and these issues are all
out of your hands, and in the hands of an algorithm for packetizing and
sending data that has very different priorities ...
--jl
-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
This archive was generated by hypermail 2b28 : Thu Oct 05 2000 - 01:36:10 EEST