[vlc-devel] Re: More clocking observations ...
gbazin at netcourrier.com
Wed Jun 4 23:41:48 CEST 2003
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.
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