On Mon, Sep 08, 2003 at 12:27:51PM -0700, Tupshin Harper wrote:
<snip>
Pre-buffering and triggering also has problems. It assumes the ability
to pre-buffer without introducing unnecessary delays. Consider the
scenario where an image and an audio clip need to be displayed with a
high degree of synchronization, but a priori knowledge of the data
involved is not available (e.g. they could be randomly selected from a
prohibitively large set of candidates). In this case, it is necessary to
*first* send the audio (or at least enough of it), and then send the
graphical event. But how is it possible to know the shortest reasonable
time to wait for the audio to get pre-buffered? There is no way to avoid
introducing some delay (just through lack of information).
It could be tested by some special diag applications. If we add triggering
and exact timing support for both audio and video output, it is at least
possible to find out, whether sync succeeds or fails (assuming the underlying
sound driver also allows it).
Lets take an application like mplayer (my favorite video stream player).
It could use extensions of X and the sound server, which allow exact
triggering (stream playback starts at timestamp XYZ). Now we should work
on both servers to work properly with this. With some test applications
it should be possible to calibrate the triggers. This could be done
manually and good-fitting values are shipped with the distro.
(just like we do with video card timings). We'll still get problems with
remote machines, but this just an question of exact measurements.
Once the X a/v sync extension is configured properly, all applications
using it, should work in sync.