More on dropped samples

[Radek Doulík]

Hi,

has this ever been fixed? I am still having problems with vlc/audio on
Powerbook/G4.

rodo

On Ne, 2001-10-14 at 22:51, Jeffrey W. Baker wrote:
> 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
> 
>