Still digging into this issue we've tryed to actived SCHEDULED and
BLOCKING mode with
the hope the it will smooth the the outgoing packet jiiter. To no
avail for the moment.
I thin that i've stumbled on a subtle bug in ortp in function
_rtp_session_sendm_with_ts
There is folliwng code:
if (session->flags & RTP_SESSION_SCHEDULED)
{
packet_time =
rtp_session_ts_to_time (session,
send_ts -
session->rtp.snd_ts_offset) +
session->rtp.snd_time_offset;
/*ortp_message("rtp_session_send_with_ts: packet_time=%i
time=%i",packet_time,sched->time_);*/
wait_point_lock(&session->snd.wp);
if (TIME_IS_STRICTLY_NEWER_THAN (packet_time, sched->time_))
{
wait_point_wakeup_at(&session->snd.wp,packet_time,(session->flags
& RTP_SESSION_BLOCKING_MODE)!=0);
session_set_clr(&sched->w_sessions,session); /*
the session has written */
}
else session_set_set(&sched->w_sessions,session);
/*to indicate select to return immediately */
wait_point_unlock(&session->snd.wp);
}
if(mp==NULL) {/*for people who just want to be blocked but
do not want to send anything.*/
session->rtp.snd_last_ts = packet_ts;
return 0;
}
I think that fact that there is a wait_point_lock between
computation of packet_time and and it comparasion
to sched->time can cause problems because the mutex call can sleep
Maybe the computation of packet_time should be moved after
wait_point_lock(&session->snd.wp);
What do you think?
Thanks
Vadim
Simon Morlat wrote:
Le
Wednesday 20 May 2009 16:40:07 Vadim Lebedev, vous avez écrit :
> Simon,
>
> I'm not sure...
> We're using portaudio and we're tryed bot pa_mme backend and
pa_dsound
> backed with similar results.
> What happens is that et the beginning of the stream we see packets
> spaced pretty regularily at 20 ms but later
> the situation degrade.
>
> I've impression that this is somehow related to regularity of
ms_ticker..
The MSTicker does a very good job, however what could produce is a
MSFilter (perhaps the portaudio ones?) that do blocking calls within
their .process method, thus slowing the whole graph processing.
>
> We're digging into it.
>
> Thanks
> Vadim
>
> Simon Morlat wrote:
> > It can also be due to waveApi buffers that are larger than 20
ms, as a
> > consequence several packets are delivered through the capture
callback
> > at the same time.
> > Linphone does this also on windows. This must not be a
problem thanks
> > to jitter buffer.
> >
> >
> >
> > Simon
> >
> > Le Tuesday 19 May 2009 17:01:54 Petr Kuba, vous avez écrit :
> > > Hello,
> > >
> > > I guess that this is caused by Windows timer which is
not enough
> > > precise to send packets each 20ms. E.g. if you try to
sleep() for times
> > > smaller than 10ms the result is very poor - sometimes it
waits for too
> > > long time and sometimes it does not wait at all.
Therefore it is
> > > typically necessary to use longer delays.
> > >
> > > Regards,
> > > Petr
> > >
> > > Vadim Lebedev wrote:
> > > > Hello,
> > > >
> > > > We're trying to use mediastreamer2 in QuteCom and
it mostly works
> >
> > well,
> >
> > > > but sometimes
> > > > we're seeing strange behaviour:
> > > >
> > > > When using G711 codec, adaptive jitter control, 20
msec packet
> > > > size... I see bursty RTP output: Each 60 ms there
is burst of 3 rtp
> > > > packets. We're using portaudio and it's on
windows/xp
> > > >
> > > > Any ideas?
> > > >
> > > > Thanks
> > > > Vadim
> > > >
> > > >
> > > > _______________________________________________
> > > > Linphone-developers mailing list
> > > > address@hidden
> > > >
http://lists.nongnu.org/mailman/listinfo/linphone-developers
|