Subject: Re: [AVT] RTP timestamps for pre-recorded audio?

From: Colin Perkins <[email-masked]>
Date: Tue, 12 Apr 2005 20:04:27 +0100

On 21 Mar 2005, at 12:21, Skill Zero wrote:
> I'm new to RTP and unsure about the right way to generate and process
> RTP timestamps. I'm hoping this is an appropriate list to ask about
> it. I've read all the related RTP RFCs and books I could find, but I'm
> still not confident I know the right way to deal with timestamps in
> code.
>
> I'm writing a server app to send pre-recorded audio over RTP and a
> client app to run on multiple computers to receive and play that audio
> (hopefully in sync). I'm using 44,100 KHz, 16-bit samples, which
> translates to 360 stereo samples per RTP packet (1500 MTU - 40 IPv6
> header - 8 UDP header - 12 RTP header = 1440 / 4 = 360) or about
> 8163.27 microseconds (not a nice number!) per packet.
>
> Since the server isn't getting audio from a live source, should I
> approximate when to send each packet using wallclock time (e.g. delay
> for ~8163 microseconds before sending each RTP packet and deal with
> the timing error accumulating later?

In theory, the receiver will be decoding into an audio buffer running 
at the same sample rate (44.1kHz) as the sender, so no timing error 
will accumulate provided the timestamp is set correctly (incrementing 
according to the number of audio samples in each packet rather than the 
wall clock time). The playout buffer at the receiver will smooth any 
variation in the actual send time in the same way it will smooth 
variation in network transit time due to variable queuing delays.

In practice, there will likely be some skew between sender and receiver 
audio clock frequency, which you will need to compensate for anyway.

> Should the RTP timestamp always increment by the sample count (360) in 
> this case?

The RTP timestamp should increment by exactly the sample count.

> When silence suppression is used, do I just have to estimate the
> number of samples that would have occurred, using wallclock time, to
> keep track of where the RTP timestamp should be for the next RTP
> packet, like this:
>
> Silence RTP Timestamp delta = (Wallclock silence end - start) * 44100?

You should be able to accurately count the number of audio samples of 
silence, and use that to determine the RTP timestamp delta.

> When using a 90 KHz rate (e.g. MPEG audio), should I convert the
> samples per frame to 90 KHz (e.g. (1152 / 44100) * 90000 = ~2351 RTP
> timestamp units per frame)? I've looked at some code that seemed to
> use the wallclock time * 90000 for the timestamp so I wasn't sure.

You derive audio timestamps from the audio samples, not the wall clock.

Colin

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt