This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

audio synchronization

0

I am trying to reconstruct two rtp streams (audio). I was using rtp timestamp as a clock rate to reconstruct and synchronization. But for few instances i see that the rtp timestamp is not linear. So how do i calculate the actual time? Is there any formula for this?

thanks rahul

asked 02 Feb '14, 21:16

rahulhgowda's gravatar image

rahulhgowda
1●2●2●2
accept rate: 0%

What does the RTP timestamp do it it's not linear? Does it jump, does it coincide with a codec change?

(03 Feb '14, 04:31) Jaap ♦

I am using kapanga soft-phone for capturing RTP and later trying to reconstruct RTP. For synchronization i am filling silence with the difference of two voice packet RTP timestamp. I see that when i mute and return back the rtp timestamp jumps lot. I also noticed that no rtp flow on mute. I was not able to handle silence insertion during this situation.

eg: G711ulaw - from wireshark

0.00 -------first packet
...
78.459090(time) - 1179(seq)---- rtp voice packet timestamp 963360
78.467873(time) - 1180 (seq) --- Comfort Noise   timestamp 963520
78.532292(time) - 1181 (seq) --- Comfort Noise   timestamp 964000
93.541290(time) - 1182(seq)---- rtp voice packet timestamp 1201760

From the above example i see that frame time for two voice packet gives the difference of(93.541290 - 78.459090 = 15.0822) where as when i do the calculations using rtp timestamp its different, ((1201760 - 963360)/8000 = 29.8). So i if fill silence for 29.8 sec my audio goes out of sync.

(06 Feb '14, 21:09) rahulhgowda

One Answer:

0

So it does jump, and there's a codec change. It's also related to a specific action (mute). These are all possible causes for the sending RTP endpoint to mess up the timestamping, and leave it to the receiver to figure out. Unfortunately there's little you can do other than follow the lead of the packet time stamps.

answered 06 Feb '14, 23:15

Jaap's gravatar image

Jaap ♦
11.7k●16●101
accept rate: 14%

thank you for the response. Actually i am trying to be a receiver here and want to reconstruct the audio. Its not exactly a codec change rather a Comfort Noise(CN) packet(Silence packet). Both codec (g711) and CN has same sample rate(8000).

So you are suggesting to use the packet time stamps.But i have concerns using this as i am using UDP as transport and there are chances of out of order packets and it may not work as desired(just a thought)

(07 Feb '14, 09:17) rahulhgowda