[vlc-devel] More clocking observations ...

j.zorko at att.net j.zorko at att.net
Wed Jun 4 23:13:37 CEST 2003


Gildas et al ...

Firstly, I do appreciate all of the work you and the rest of the VideoLAN team have put into this 
project ... even with it's flaws, it's quite impressive and, once its' issues are worked out, it promises 
to be one of the best media players, for any platform.

That being said, i've made some progress on the clock skewing problem relating to seeking a lot.  
If I modify input_ClockManageRef() thusly:

*****************************************************************************
 * input_ClockManageRef: manages a clock reference
 *****************************************************************************/
void input_ClockManageRef( input_thread_t * p_input,                           pgrm_descriptor_t * 
p_pgrm, mtime_t i_clock )
{
    /* take selected program if none specified */
    if( !p_pgrm )
    {
        p_pgrm = p_input->stream.p_selected_program;
    }

    if( ( p_pgrm->i_synchro_state != SYNCHRO_OK ) || ( i_clock == 0 ) )
    {
        /* Feed synchro with a new reference point. */
        ClockNewRef( p_pgrm, i_clock, mdate() );
        p_pgrm->i_synchro_state = SYNCHRO_OK;

        if( p_input->stream.b_pace_control
             && p_input->stream.p_selected_program == p_pgrm )
        {
            p_pgrm->last_cr = i_clock;

printf( "* synchro not ok* PCR clock -- waiting %qd before reading more data\n", i_clock );

            mwait( ClockToSysdate( p_input, p_pgrm, i_clock + 35000 ) );
        }
        else
        {
            p_pgrm->last_cr = 0;
            p_pgrm->last_syscr = 0;
            p_pgrm->delta_cr = 0;
            p_pgrm->c_average_count = 0;
        }
    }
    else
    {
    .
    .
    .
}

This was just an experiment.  Since I noticed that the mwait() call in the synchro case (right after 
the printf() I added) was always returning immediately (time had already passed), and since this 
was getting called after every seek, and since my ff / rew stuff seeks a lot, I figured that this may 
be the gate that was left open to the FIFO, if you dig.  So, I noticed that the average time for the 
MP3 frames of the 320K MP3s that iTunes made for me was about 32000 or so, so I added 35000 
to the time to mwait() for.

Result: much much better ... I can ff / rew to my hearts content, and the audio never speeds up at 
all.  It occasionally played slower, probably 'cuz that number is just a rough estimate and could be 
lower (and most likely is sometimes, being dynamic).

This isn't a fix, just an observation i've made that leads me to believe I may be able to fix this nasty 
bug today, once I grok the clocking code a little better.  Am I on the right track?  Any comments 
from anyone?  Am I way off?

Regards,

John

--
Falling You - exploring the beauty 
of voice and sound
http://www.mp3.com/fallingyou








-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>



More information about the vlc-devel mailing list