[MPlayer-dev-eng] [PATCH] DXR3

[David Holm]

> I don't agree with this change. It looks like as an ugly workaround than a
> fix or so. Order or audio and video decoding MUST NOT affect a-v sync of a
> given libvo driver...
> 

Would you allow a modification that would add a call to
(vo_device)->reset (just like ao_device->reset is called on seek/pause)
and wait for it to finish before sending audio data? IMHO it's not fair
that the ao_device get's a call to reset when a seek occurs but the
vo_device does not have this advantage. Keep in mind that the windows
software for the dxr3/h+ MUST use the audio capabilities of the dxr3,
and you must use the proprietary software provided by creative/sigma to
play movies. In linux we have a choice of not using the em8300's audio
capabilities, but instead use your standard audio device for instance.

The em8300 can prebuffer frames, this is possible with flag 0x100 but
sync is broken on seek. This is a new way of playing videos since it
does not render frame by frame but rather tries to render as many frames
ahead as possible, therefore you cannot assume that the em8300 can be
interfaced just like a normal video device. I need either to assume that
audio data is sent to the buffer AFTER video data, or that mplayer.c
calls a vo_dxr3->reset and waits for it to return before writing audio
data, otherwise features will be lost.

I can give you a clean patch to implement this (without disrupting the
other vo-devices, or by adding empty reset()'s to them), but I want
clearance first.

//David Holm