Subject: RE: [AVT] Query on Audio stream clock tolerance

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 3 Aug 2001 00:29:25 -0400

> -----Original Message-----
> From: SUBHAS C MONDAL [mailto:[email-masked]]
> Sent: Friday, August 03, 2001 12:09 AM
> To: [email-masked]
> Subject: [AVT] Query on Audio stream clock tolerance
> 
> 
> Hi,
> 
> I am new to this area. Could someone help me on the impact of 
> clock speed
> variance on Audio Quality. Let me explain the scenario.
> 
> Originating source smaples voice at (8Khz - 100ppm) clock 
> rate and produces
> a 64kbps digital stream.
> The data gets transmitted over IP to the Receiving end and is 
> played back at
> (8Khz + 100ppm).
> 
> The scenario is for a PC to PC communication using RTP as the media
> transport protocol.
> 
> My question is, what would be the effect of this clock speed 
> variance on the
> voice quality both in forward and reverse direction?

Clock skew manifests itself as low-frequency jitter. As a result, the best
way to handle it is through the jitter buffer. The buffer will gradually
empty because the terminating clock is faster than the originating. The
terminating side therefore inserts a frame into the buffer to handle the
underrrun, which gives it enough data to continue processing until the next
eventual underrun, when the process repeats. 

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: "SUBHAS C MONDAL" <[email-masked]>
Date: Fri, 3 Aug 2001 10:45:43 +0530

Hi Jonathan,

thank you for a prompt response. I have tried the jitter buffer mechanism.
This definitely improves the audio quality to some extent. The quality issue
I am facing varies from PC to PC.

I have tried the following algorithm on the receive side. The quality
improves but is not very good for some PC combinations. Could you please
look into my algorithm and suggest an improvement?

There are 50 circular buffers of 160 byte packet size. In the following
description, a 160 byte packet is described as a frame. Incoming data is
written in the Circular buffer and "Wr Pointer" points to the current
location. The data is played back on a sound card. The "Rd pointer" points
to the current location of data being read out to the sound card. When the
sound card finishes playing 1 frame, it generates an event named
"send_next_frame". Playback buffer refers to the number of buffers allocated
to the sound card.

Case 1: Wr speed is faster than the playback speed.

This would happen if the Tx speed of the source RTP stream were faster than
Playback speed on the Rx side. Event send_next_frame would be generated at a
slightly slower rate than incoming frame rate. As a result, the Read
operation would be slower than the write operation. This would make Wr
pointer move ahead of Rd pointer until it catches up the Rd pointer. When Wr
pointer crosses over Rd pointer, data of 50-frame duration would be
over-written. This would cause a data loss for 1 sec duration and the data
just written would be played back. The only thing that needs to be done to
avoid collision between Rd and Wr pointer would be incrementing Wr pointer
when they collide.

Case 2: Wr speed is slower than the playback speed.
This would happen if the Tx speed of the source RTP stream were slower than
Playback speed on the Rx side. Event send_next_frame would be generated at a
slightly faster rate than incoming frame rate.

The algorithm:

Initially, the circular buffer is filled with 25 frames. 20 frames are read
on the sound card buffer. Now Wr pointer is ahead of Rd pointer by 5 frames.

Considering a 20 frame initial buffering to the Playback buffer, the Wr
pointer would point to frame 26. When the first frame is played back, the Rd
pointer would point to frame 21 and this continues. If the read is faster
and Rd pointer is behind Wr pointer by 1, the Read pointer is decremented by
4. Thus we repeat 4 frames and bring back the difference. When Wr pointer is
moving faster and the Wr is ahead of Read by 10, I increment Rd pointer by
5. Thus, we skip 5 frames and bring back the difference.

The frequency of Rd-Wr catch up could be reduced by changing the initial
difference between Rd and Wr pointer. This would have implication on the
delay. Please suggest me an optimal value.

Thank you very much for your patience.

Regards,
Subhas

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Friday, August 03, 2001 9:59 AM
To: 'SUBHAS C MONDAL'; [email-masked]
Subject: RE: [AVT] Query on Audio stream clock tolerance

-Jonathan R.
---