26 Feb
2004
26 Feb
'04
2:53 p.m.
Hi everyone,
Sorry about sending random ASCII to the list, I
was editing a "is this, or is this not, RTP" reply and I
clicked the wrong button (oops). Basically, I should
note that
[1] Low-latency itself is not a problem with RTP --
if one runs RTP over a transport with low latency,
it can fully utilize the latency, see:
http://www.cs.berkeley.edu/~lazzaro/sa/pubs/pdf/nossdav01.pdf
[2] RTP came out of the multi-cast WAN videoconferencing
world (early 1990s) and then slowly migrated into other
domains (like content-streaming, etc). The Peak folks, like
the MIDI Show control folks, came to the problem from the
LAN direction. That said, any LAN that is running IP can
set up a link-local multicast group and run RTP on top of it,
and access the "broadcast" nature of the LAN environment.
[3] The problem Peak solves in hardware is akin to the
problem SPDIF and AES/EBU solves in hardware -- if the
sender and receiver have free-running clocks, sooner or
later underflow or overflow occurs, and so if your goal is
to "never click", you have to address the issue somehow.
Note this isn't an issue with non-continuous-media RTP
payload formats like RTP MIDI, as the command nature
of MIDI lets you slip time without artifacts. Neither is it an
issue for voice codecs used in conversational speech,
because you can resync at the start of each voice-spurt
(packets don't get sent for the side not talking -- this is part
of the efficiency advantage of VoIP over switched-circuit telephony).
For continuous-stream audio over RTP, the state of the art
to avoid this problem is a software sample-rate converter on
the receiver end, which speeds up or slows down the
sample rate of the sent stream by tiny amounts to null out
the tiny differences from "nominal" in the sender and receiver
sample-rate clocks. Quicktime does this, according to a thread
on the AVT mailing list a few years ago that discussed this issue.
Note this method isn't modifying the actual sender's sample rate;
on the contrary, its modifying the receiver's actual sample rate
to match the intentions of the sender.
---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---