Re: [Linphone-developers] oRTP jitter control problem on BlackFin 537-stamp

[Simon Morlat]

Hi,

The jitter buffer algorithm of oRTP uses RTP's timestamps of the incoming 
stream and a "user timestamp" given by the application, representing the 
application local time.
In linphone/mediastreamer2, this user timestamp is computed from 
gettimeofday()/clock_gettime(), which has a clock that can be slightly 
different from an audio device.
With standart PC's, the difference between the two clocks is so small that 
there is no problem.
But in an environnement where either:
- the audio device/driver is a little bugged and samples at more or less than 
8000Hz
- or the gettimeofday/clock_gettime() is imprecise
an incorrect behaviour of the jitter buffer can occur.
Theoritically, the user timestamp should be derived from the audio device. 
However because it's difficult for design reasons, in mediastreamer2 
clock_gettime() is used instead.
I suggest that you try to make measurements of the audio device sampling rate 
(=compute the average number of samples acquired over a dozen of seconds), 
and check the accuracy of clock_gettime() implementation.
The solution could be
- improve/fix the driver/audio device so that it does accurante sampling (does 
not miss buffers for example)
- replace something clock_gettime() in mediastreamer2 with something else ...

Hope this helps!

Simon


Le Wednesday 14 November 2007 18:07:04 Glenn Hessler, vous avez écrit :
> Simon, thanks for the response.
>
> My printf's show that the delays consistently occur well after audio
> startup. Depending on the jitter compensation value, they
> usually occur every 5 seconds or so.
>
> I assumed that the jitter works correctly, since it is fundamental.
> My concern is how it has been implemented on the BlackFin platform by ADI.
> Could be a scheduling issue?
>
> Are there currently people using Linphone with
> the BlackFin processor on an embedded
> platform with uClinux?   More specifically, the BlackFin 537-Stamp?
>
> Thanks again..
>
> At 08:44 AM 11/14/2007, you wrote:
> >Hi,
> >
> >The problem seems more related to the time between the opening/start of
> > the audio device and the writing of the first packet to the audio device.
> > The bigger the jitter buffer is, the bigger this interval is.
> >Probably a audio driver problem (this is quite frequent).
> >I can insure you that the jitter buffer of oRTP is working well (it used
> > in various professional products and tested by hundreds of end-users).
> >
> >Simon
> >
> >Le Friday 09 November 2007 00:12:47 Glenn Hessler, vous avez écrit :
> > > I am trying to get jitter control to work on the receive side of a
> > > Linphone call,
> > > and am experiencing some strange behavior.
> > > When I increase the jitter compensation value(linphonerc), it causes
> > > underrun conditions in the sound driver(alsa).
> > > I have found that the larger the jitter compensation value, the
> > > longer the duration
> > > of the underrun condition.  I have documented this below.
> > > I am running on an ADI BlackFin 537-Stamp board, running Linphone 1.6.0
> > > on uClinux 2.6.22.10.
> > >
> > >
> > > By printing the timeofday before each write, I have found the
> > > following:
> > >
> > > 1. When audio_jitt_comp != 0, the delays that cause the xrun condition
> > > are directly related to the value of audio_jitt_comp. If
> > > audio_jitt_comp=100, every so often there is a 100ms delay between
> > > writes from Linphone to alsa. When this occurs the driver reports it is
> > > in xrun condition.  If audio_jitt_comp=200, the delays causing xrun are
> > > 200ms. etc..
> > >
> > > 2. When audio_jitt_comp == 0, every so (less)often there is a ~60ms
> > > delay between writes from Linphone to alsa. When this occurs the driver
> > > reports it is in xrun condition.
> > >
> > > Obviously, the Linphone jitter control is not working as intended when
> > > the value is non-zero.  Jitter buffering should smooth any jitter, not
> > > make it worse.
> > > When jitter is 0, the xrun may be a delay up through the stack and the
> > > Linphone.
> > > I have confirmed these results running linphonec and mediastream
> > > applications. With the following printf's in alsa.c:
> > >
> > > //---------------------------------------------------------------------
> > >- static int mycount=0;
> > > static int alsa_write(snd_pcm_t *handle,unsigned char *buf,int
> > > nsamples) {
> > >          int err;
> > > //--------
> > > int res;
> > > struct timeval ot;
> > > snd_pcm_status_t *status;
> > > snd_pcm_status_alloca(&status);
> > > if ((res = snd_pcm_status(handle, status))<0) {
> > >          exit(EXIT_FAILURE);
> > > }
> > > if (strcmp("XRUN",
> > > snd_pcm_state_name(snd_pcm_status_get_state(status)))==0)
> > >      printf("XRUN\n");
> > > //printf("%s\n",
> > > snd_pcm_state_name(snd_pcm_status_get_state(status)));
> > > gettimeofday(&ot,NULL);
> > > //printf("%d  %d\n", nsamples, (int)ot.tv_usec);
> > > printf("%d  %d\n", mycount++, (int)ot.tv_usec);
> > > //---------
> > >          if ((err=snd_pcm_writei(handle,buf,nsamples))<0){
> > >                  if (err==-EPIPE){
> > >                          snd_pcm_prepare(handle);
> > >                          err=snd_pcm_writei(handle,buf,nsamples);
> > > gettimeofday(&ot,NULL);
> > > printf("prep %d  %d\n", err, (int)ot.tv_usec);
> > >                          if (err<0) ms_warning("alsa_card_write:
> > > Error writing sound buffer
> > > (nsamples=%i):%s",nsamples,snd_strerror(err));
> > >                  }else if (err!=-EWOULDBLOCK){
> > >                          ms_warning("alsa_card_write: snd_pcm_writei()
> > > failed:%s.",snd_strerror(err));
> > > printf("block\n");
> > >                  }
> > >          }else if (err!=nsamples) {
> > >                  ms_warning("Only %i samples written instead of
> > > %i",err,nsamples);
> > > printf("%d\n", err);
> > >          }
> > >          return err;
> > > }
> > > //-------------------------------------------------------------------
> > >
> > >
> > > Is this a known problem on the BlackFin platform?  Could you provide
> > > some input?
> > >
> > > Thanks...
>
> _______________________________________________
> Linphone-developers mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/linphone-developers