[vlc-devel] Re: More clocking observations ...

[Gildas Bazin]

On Wednesday 04 June 2003 23:13, j.zorko at att.net wrote:
> 
> 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?
> 

You will find the real problem in modules/demux/mpeg/audio.c. Looking at the 
way the mpeg audio demuxer emulates PCRs, you don't need to reset the clock 
after a seek().
Just try to put: p_pgrm->i_synchro_state = SYNCHRO_OK; just before the call 
to input_ClockManageRef(). That should take care of the problem.

--
Gildas

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