[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Glenn Hessler
Subject: Re: [Linphone-developers] oRTP jitter control problem on BlackFin 537-stamp
Date: Wed, 14 Nov 2007 09:07:04 -0800

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:

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


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]