Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > VOIP > rtp implementation issues ?

Thread Tools

rtp implementation issues ?

Posts: n/a

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
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

(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
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 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

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

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


Reply With Quote
Le Chaud Lapin
Posts: n/a
Ram wrote:
> Hi,
> I am trying to implement a light weight RTP Stack on my
> own. However, it didnt work.

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-

Reply With Quote

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
RTP: Who will deny odd RTP (UDP) port numbers? CCGolfer VOIP 0 06-08-2004 08:39 PM
RTP packets not received at PC side Guan Yang Cisco 2 03-07-2004 12:06 AM
Class-Based RTP and TCP Header Compression love0503hk Cisco 0 01-25-2004 05:08 PM
RTP priority configuration Weiguang Shi Cisco 1 11-09-2003 11:10 PM
about "match ip rtp starting-port-number port-range" Weiguang Shi Cisco 1 10-25-2003 07:14 AM