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