rtp implementation issues ?

Hi,

I am trying to implement a light weight RTP Stack on my own. However, it didnt work. So, i thought of studing a few exsisting rtp implementations.

After observing the workings in my code for say 100000 pkts many times over and over. I could conclude, 1) process scheduling 2) Precision of select call (suppose i call select with 4ms delay) some times it would return by say 6ms or say after

60ms.

(u never really know).

However, as i am going thru other implemenations. i find that this aspect is completely ignored. i really dont know whether i am wrong or not ?.

However the sound quality of other implementations are better than my own.

I dont know why ?. do u have any idea of how this is taken care of ?.

In some code, something is said like clock slide (say this implementation, takes care of a 3% clock slide, i really dont know what this clock slide is ?.

do u know what it is ?.

In the sender, i just read from audio, attach the timestamp and send it in a loop. say, if i need 4ms data, read call does not take 4ms.it takes less than that say 1ms, sometimes 2ms and so on. ( i tested this by having gettimeofday before and after read).

This results in a faster sender and a reciever (who picks up the packet from the Queue of packets at periodic intervals)

i tried sleeping of the appropriate number of ms after the read using select and it didnt work ?.

do u know how this is taken care of ?.

In the reciever what i do is - i get a packet (say 3ms) write it to audio buffer and sleep for 3ms and then check if i have the packet and play the packet if it is present if not i play the previous packet.

this is the logic and it sounds correct to me.

Actually, if i say all packets are 3ms data pkts. i use select for

1.5ms (after the select returns (i assume it to return before 3ms) i check for the pkt and do the appropriate thing (play last packet or play present pkt).

(this i am doing to prevent the audio driver buffer from underflowing).

please do advice, if u think i am going wrong somewhere.

I am using 48KHZ audio, 2 channels and 4 bytes/sample.

Regards, sriram

By now you probably realized that the variance in inter-packet period is unavoidable.

You can artificially get rid of this variance by matching your sampling rate as close as possible to your playback rate. You will need to use interpolation, which means you will need a buffer at the playback end, which means accumulation, which translates into necessary delay from input to output. You will need to over-sample the input data, say, at N-times your true input sampling rate to generate intermediate false samples. You can assume that the curve between two true samples is linear for simplicity. Create associated time stamps with the false samples. Then, on playback, instead of playing back real samples, playback the false samples corresponding to whatever the output timer expects. If your true input sample rate was high enough to start with (did not violate Nyquist Sampling Theorem), the audio should sound a little better after interpolation.

-Le Chaud Lapin-