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

[Simon Morlat]

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