More on dropped samples

[Jeffrey W. Baker]

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

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?

-jwb