[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Linphone-developers] ortp: processing incoming stream

From: Filipp . Andjelo
Subject: [Linphone-developers] ortp: processing incoming stream
Date: Thu, 26 Nov 2009 13:48:16 +0100


I need a little bit help on receiving packets using oRTP again.  I have to deal with many RTP Sessions, using scheduled, non-blocking mode and own payload type, The length of each packet is 60ms (at 8kHz, timestamp incrementor of 480). The software I'm writing is not an end device, It's s.t. like a switch, so packets should be transfered as fast as possible to minimze the overall delay. But the internal oRTP scheduler don't like my plans and causes  additional avarage delay of one packet length (60ms).
Experiments with jitter settings brought nothing, but after enabling some debug output I've noticed following:

26/11/09 02:21:15.916 rtp_session_recvm_with_ts: packet_time=10, time=10
26/11/09 02:21:15.917 rtp_session_recvm_with_ts: packet_time=70, time=10
26/11/09 02:21:15.980 rtp_session_recvm_with_ts: packet_time=130, time=70
26/11/09 02:21:16.036 rtp_session_recvm_with_ts: packet_time=190, time=130
26/11/09 02:21:16.095 rtp_session_recvm_with_ts: packet_time=250, time=190
26/11/09 02:21:16.156 rtp_session_recvm_with_ts: packet_time=310, time=250

You see in the fist two lines the time of the scheduler stays constant at 10 and then begins to grow, so the received/required packets are at the feature and would be received 60ms later. Is there a possibility to get the packets in time using the build in scheduler?

Another problem I had with SENDRECV sessions, it is not possible to use scheduler with blocking mode in that case. Since _select() doesn't work properly with blocking  for receiving, but needs to be blocked on sending. So now I'm sending directly without _select() and receiving with _select() in blocking mode. Is this behavior expected, or am I doing s.t. wrong? By the way, in the oRTP examples for the handling of many sessions, there is blocking mode used for sending and non-blocking for receiving, but  for SENDRECV sessions you need both. I think I don't understand something, but I would appreciate to make a clean solution.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]