linphone-developers
[Top][All Lists]
Advanced

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

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


From: Glenn Hessler
Subject: [Linphone-developers] oRTP jitter control problem on BlackFin 537-stamp
Date: Thu, 08 Nov 2007 15:12:47 -0800

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







reply via email to

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