Re: [linux-audio-dev] Distributed audio processing

New Message Reply About this list Date view Thread view Subject view Author view Other groups

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
-------------------------------------------------------------------------


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Oct 05 2000 - 01:36:10 EEST