[MPlayer-users] Re: A/V sync problems

[Lawrence A. Rowe]

Peter Schuller wrote:
> 
> problems maintaining a/v sync
>

Hi -

I just dropped into this list and saw this message.  I have an idea what
the problem is, but you're not going to like it.  Does the problem
show-up when you play for an extended period of time?  It might take 3-5
minutes of playing before the sync drift is noticable, depending on the
audio card, but if you play for an hour, or better yet, do a 24 hour
test, and you'll see it for sure.

Here's the issue.  Turns out that our sound cards do not perform quite
as expected.  If you say grab or play 8,000 16-bit samples per second,
depending on the card you will get anywhere from 7,992 to 8,008 samples
played and the number may vary from second to second.  This problem has
been around for a long, long time.  Now, if you capture samples to a
file and replay them, there is no problem stretching or shrinking the
replay because you have no reference to compare against. But, once you
put video with the audio, or some other perceptual reference, you will
run into trouble because the drift, if uncorrected will become noticable
very quickly - like within 2-3 minutes.

Remember, humans have the ability to perceive very fine time 
distinctions.  Experienced music afficionados can detect, and are
annoyed by, a downbeat that misses by 1 msec.  And, humans require lip
sync to be correct in audio+video by audio arriving within [-15,+33]
msecs from the frame time when it should appear for NTSC.  That range is
[-20,+40] for PAL/SECAM for obvious reasons.  You can do some simple
math to show why you run into trouble.  Let's suppose your playout is
off by just 4 samples per second - in other words you play 4 samples too
few.  well, that's 4/8000 of drift.  how many seconds before you've
drifted 33 msecs - by my calculation it would be 66 seconds which is
just over a minute.  hummmm.

So, how can software fix this problem.  You can but the audio drivers
have to be changed to provide some additional feedback to the apps. I
had a graduate student who developed a high-quality streaming a/v
system, called RTPtv, which dealt with this problem so we could maintain
24 hour sync on our streams.  His masters report, available at
	http://www.bmrc.berkeley.edu/papers/2001/161/
describes the problem in detail and the algorithms for solving them.
Source code is also available if you want to plow through what he did.

Of course, now that I've stuck my nose into this discussion and claimed
to have "the solution" someone will send email "stupid you, we already
know about that and fixed it" or "arrogant AH, that isn't the problem."
If so, I apologize for pontificating.  I do it because I have dealt with
this problem for years, and I am hopefully you can contribute pressure
to get the various sound device driver folks to add the required
features.
	Larry Rowe
-- 
Professor Lawrence A. Rowe          Internet: Rowe at BMRC.Berkeley.EDU
Computer Science Division - EECS       Phone: 510-642-5117
University of California, Berkeley       Fax: 510-642-5615
Berkeley, CA 94720-1776            URL: http://bmrc.berkeley.edu/~larry