Jerky playback Dharma B2 and SVN /Ion

TheSwissKnife Wrote:I have played with this setting but am still not sure what it is doing. How does it determine the frequency of vertical blank? Is "vertical blank" in this context the same as vsync?

I always see from codec-info screen that it says it adjusts by 0.1% regardless of what I tweak my modelines too as if it is massively rounding up and assuming 23.976 versus 24.000. Is it not designed to work in the case where the refreshrate is out by a little (eg 23.9764 refreshrate with 23.976024 fps source material)?

It always rounds the refreshrate, that's not a problem, the clock speedup cancels it out.

Ok thanks I think understand. So this mode plays around with the audio as best it can to match the vsync it sees from graphics card.

Without this option but with VSync enabled I assume it should therefore never adjust the audio (drop/dup audio packets or adjust audio clock)?

I am noticing that in this simple Vsync enabled mode, the a/v value in the codec info screen might give a clue to the discrepancy between the audio clock and the VSync rate (refreshrate) as it drifts. I see XBMC letting it drift up to about 10ms before correcting it somehow - the question here is then what is the somehow? The starting min and max seems dependant on the audio setup eg in Windows the DirectSound HDMI mode gives different values that the WASAPI HDMI mode.

When using the audio clock sync method, dvdplayer checks the difference between the clock and the audio stream, if the difference is more than 10 ms, it sets the clock to the time of the playing audio stream.

The video stream is referenced to the same clock, that's how audio and video are synchronized.

That is not what I observe. If I don't set the "sync to display" option I see the behaviour you just described, and DEBUG log mentions the audio discontinuity of 10000.xxxx etc, without mention that it is setting the clock back/forward. This is why I was asking as can't quite get what is the difference between the setup of:

VSync enabled, "sync to display" disabled

VSync enabled "sync to display" enabled, "Audio clock" adjustment

at least in the case where the fps is very close to the refresh rate.

They "seem" to be virtually the same. I assume both never drop audio packets? Does the former ever drop/dup video frames?

The difference is, with sync playback to display enabled, the vertical blank is used as the clock, instead of the system clock, but this won't help anything if you still get a lot of discontinuity errors, becaus eventually some videoframes will be shown too early or too late anyway.
The drop/drupe and resample sync methods solve that.

It seems you are saying that without the sync to display video frames will inevitably be dropped/duped if system clock does not match video refreshrate for the frame times (and this is independant of the audio) - did I get that right? But then for the audio without "sync playback to display" there are no options to tell xbmc how to deal with discrepancies (drop/dup audio, adjust audio clock) - what decisions does/can it make? This is not clear at all to me at least. When I see the audio discontinuity debug message - does that actually tell us what xbmc has done to workaround this (clock adjust or dup/drop etc)?

As for with the sync to display mode, it seems resample audio isn't much use because of the passthrough case, but the other two cases are possible, but I don't see how to decide when it be better to drop/dup packets instead of adjusting clock - what do you need to look for to see that the better audio clock method is not coping?

TheSwissKnife Wrote:It seems you are saying that without the sync to display video frames will inevitably be dropped/duped if system clock does not match video refreshrate for the frame times (and this is independant of the audio) - did I get that right? But then for the audio without "sync playback to display" there are no options to tell xbmc how to deal with discrepancies (drop/dup audio, adjust audio clock) - what decisions does/can it make? This is not clear at all to me at least. When I see the audio discontinuity debug message - does that actually tell us what xbmc has done to workaround this (clock adjust or dup/drop etc)?

When sync playback to display is off, the sync method defaults to audio clock, there's no point in using anything else.

Quote:As for with the sync to display mode, it seems resample audio isn't much use because of the passthrough case, but the other two cases are possible, but I don't see how to decide when it be better to drop/dup packets instead of adjusting clock - what do you need to look for to see that the better audio clock method is not coping?

With passthrough you have only one option, you need a refreshrate that matches the video fps, if you don't have that, you're screwed, nothing can be done to fix that.

bobo1on1 Wrote:When sync playback to display is off, the sync method defaults to audio clock, there's no point in using anything else.

That makes sense (I think) and explains what I see.

Quote:With passthrough you have only one option, you need a refreshrate that matches the video fps, if you don't have that, you're screwed, nothing can be done to fix that.

But I am currently using passthrough and without the sync to display - I don't get what it means to match the fps with the refreshrate since the fps only means something in respect to a reference clock right? In this mode I see the audio discontinuity message of 10000.xxxx every say 15mins - and you say that this means it is adjusting the audio clock - so why am I screwed? System clock or audio clock - I am getting lost!


In the thread that explains this "sync to display" (where you are the author I think) it says only that the resample method does not work with passthrough - is this incomplete then?

The purpose of my queries is to try to determine what I need to look for to tweak my refreshrate to exactly the correct value (or pretty close). With MPC-HC I believe I have to adjust the refreshrate until the drift in the render info graph is reduced enough - I managed to get this down to 1ms per 8 mins. The very same refreshrate causes the a/v value to drift quite quickly in XBMC (eg 1ms every 1min30). So now I don't know what exactly I am trying to sync the refreshrate to (visibly) with XBMC.

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.

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?