More on dropped samples

Jeffrey W. Baker jwbaker at
Mon Oct 15 04:51:11 CEST 2001

My last mail was incorrect.  It seems that vlc already decides the correct
amount of time for sleeping.  The real problem is that vlc sometimes
spends too long in S16StereoPlay, and the bluk of the time is spent in

I am examining timing output, and the majority of the time in NextFrame is
spent waiting on this condition (aout_common.h):

        while ( p_fifo->l_next_frame == p_fifo->l_end_frame )
            vlc_cond_wait( &p_fifo->data_wait, &p_fifo->data_lock );
            if ( p_fifo->b_die )
                vlc_mutex_unlock( &p_fifo->data_lock );
                return( -1 );

Before a particular underrun, vlc spent 71ms in this loop, out of a 100ms
slice.  S16StereoPlay overall took 81ms, some other stuff took a little
while, and the usleep spent slightly long that it should have.  All
together, the next 100ms of audio arrived 2ms late.  The underruns range
from 0-20ms.

Is there something that can be tweaked to make the data arrive on time?


More information about the vlc-devel mailing list