Re: [Linphone-developers] Bursty rtp traffic

[Simon Morlat]

Hi Vadim,

I think you are right regarding the place the mutex should be hold.
I'm going to make the change now.
Regarding the output jitter, I'm not sure that the scheduled+blocking mode is the solution. This mode was done mainly for streaming from disk, for programs that wouldn't have their own ticking mechanism. But mediastreamer2 has MSTicker, thus doesn't need this mode.
The bigger problem you might have is when the soundcard delivers more samples than the real time. rtp_session_sendm_with_ts will then block the entire MSTicker, and samples will accumulate within the stream.
I think a better approach would be to either improve the sound capture filter so that it has a lesser latency, or implement a smoothing filter at the output of the capture filter.

Simon

Le Wednesday 03 June 2009 15:39:16 Vadim Lebedev, vous avez écrit :
> 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