More on dropped samples

[Hamish Marson]

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

But that's exactly where vlc SHOULD spend it's time... i.e. idle... The
cond_wait is (presumably) mapped to pthread_cond_wait, which will put a
thread to sleep until the condition is met (i.e. something is broadcast to
the condition variable). Thus you'd see the thread spend large amounts of
real time in there because it's mostly idle...

What's probably not happening is the wakeup happening in time... Perhaps the
condition needs to be at a higher priority, using real time scheduling?

H


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

--

I don't suffer from Insanity...
        I enjoy every minute of it...