> Please remember that i live in NTSC-land, and all my video material
> is NTSC.
> So, i tried the latest stable xine-lib/xine-ui (downloaded the
> src.rpm's from Freshrpms and rebuilt'em on my system) on Red Hat 9
> with the DXR3 CVS tarball made by Marcel Janssen.
> The sound was routed through ALSA to a SBLive card, using the digital
> I played various DVDs, some of them pure interlaced 29.97 NTSC stuff
> (made by myself from mini-DV digital tapes shot with an amateur
> camcorder - conversion accomplished using transcode as a media
> framework, mjpegtools as a MPEG2 codec, dvdauthor as an authoring
> software), some other being commercial film material (23.9) telecined
> into 29.97 fps.
> Try as i might, i couldn't sense any "bumpiness" or other image flow
> problems. Nothing at all. I'll try some more if i get some time to
> spare (unlikely) but i strongly suspect there is no such problem on
> my system. However, i did notice a problem with the telecined stuff:
> the image/sound synchronisation drifts away slowly. After like 30..40
> minutes, it becomes noticeable. If i skip back to a previous chapter,
> and then skip again to the current chapter, xine gets back into sync.
> I didn't tested too much the pure interlaced 29.97 stuff, so i can't
> tell if there's any desync stuff there as well.
> This problem is new to me. Without DXR3, i didn't notice any sync
> problems on that system, no matter which player i use.
If you can remember: Have you experienced these problems before with the
> Would it be possible that it's the same issue, that on some systems
> manifests itself as bumpiness, and on some other as
> desynchronisation? I didn't try the patch, but i'll do my best to
> find some time to test it.
The patch should only change behaviour for non-MPEG content.
> Anything else i should try?
The problem here is the two independent clocks (DXR3 and the SPDIF
clock), which both time their respective streams (video and audio)
relentlessly. If these two clocks do not run in perfect sync, audio and
video will drift apart and there is not much you can do about it.
You can disable sync playmode for the dxr3 (dxr3.alt_play_mode) and
maybe even enable per-frame syncing (dxr3.sync_every_frame), then the
dxr3 will give in if the stream's PTS and the internal clock drift
apart, but you might see small jumps in the image (frames dropped or
The only real solution is to route the digital audio through the dxr3 as
well. This way, everything will be synced by the same clock. I believe
this is the reason why the dxr3 windows player does not allow you to
use a soundcard other than the dxr3 at all.
printk("ufs_read_super: fucking Sun blows me\n");