bobo1on1 Wrote:During playback, press 'o' and look at the sync value, you want that to remain stable.
You could also look at the interval between discontinuities in the xbmc debug log, or the interval between packet drops/dupes when using the drop/dupe sync method.
But that is what I have been doing all along and I assume you mean the "a/v" sync value - if so that is what I have been referring to.
Basically without using the "sync to display" option (to build the clock from vsync) I am trying to understand how to tune my refreshrate to the best value. I am using 23.976 material to begin with and NVidia NG-ION and currently using Windows 7 as it seems to have less issues than Linux (now there is DXVA2 support).
So this "a/v" value is drifting which I think from you are writing implies that based on the system clock the audio and video are slowing moving out of sync. Assuming for now that the source material is perfect (23.976024) encoded then this means either the vsync frequency (ie refreshrate) is not correct or the system clock frequency is not correct or both - am I right?
If so, I don't understand where the "audio clock" fits into this though.
I also don't understand your comment that the refreshrate must exactly match when using passthrough - I would assume that passthrough is or will be the preferred mode of operation. So with passthrough is it or isn't it possible to drop/dup audio or to adjust "audio clock" (whatever that is)?
If there was no audio in a file could I still see a discrepancy between system clock and vsync rate in any of the info produced by XBMC?