jitter and playout delay computations!!!

Hi, I had posted a query lastweek regarding jitter computation and playout delay.

since, no one responded to it i am posting it again:

We have the interarrival jitter computation:

int transit = arrival - r->ts; int d = transit - s->transit; s->transit = transit; if (d < 0) d = -d; s->jitter += (1./16.) * ((double)d - s->jitter);

how do we compute the jitter buffer required (num of packets to be buffered before we begin to playout)

how playout delay and num of packets to buffer (size of jitter buffer) is computed from s-> jitter(inter arrival jitter).

Regards, John

Reply to
John
Loading thread data ...

What class is this for and what are you offering if we do your homework for you? ;-)

-wolfgang

Reply to
Wolfgang S. Rupprecht

Well, what can i offer you expect, that i will be greatful to u and i promise that if anybody needs to know something which i already knew i will share my knowledge i have gained from all of you.

i am not a student. i am looking for work and am trying to understand rtp so that it could enhance my prospects.

Regards, James Wolfgang S. Rupprecht wrote:

Reply to
John

Sorry for doubting. The lack of verbiage and detail made it sound a bit like a homework problem.

When you posted it the first time, I did wonder what google had on it so I poked around a bit. Now I may have gotten things a bit wrong, but it sure looked to me like the units were dimensionless (not time at all) but simply the audio sample count. Typical 20ms rtp packets had a value of 160 samples and the "timestamp" would increment by 160. (I take it at some point in the past that timestamp was truly a time value, but as people used different sample rates it was easier to just count samples directly.)

(* 8000 ; samples per second for alaw/ulaw 20e-3) ; 20ms rtp packet

160.0 ; samples/packet

It might be interesting to grab a copy of some open source voip software (kdephone, linphone) and observe it in action (say by adding printf's for logging the RTP headers). Both of those programs are still fairly rough around the edges and an interested party tweaking things and fixing bugs could still make a significant contribution.

-wolfgang

Reply to
Wolfgang S. Rupprecht

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.