Reply to thread

Message

<blockquote data-quote="tourettes" data-source="post: 609205" data-attributes="member: 10858">Jong, do you know the logic that ReClock uses when the &quot;correct v-sync&quot; option is enabled? I personally don't use ReClock since #1 I have been blessed with two PCs that have such small drift between audio and GPU clocks that they cause only one or two out of time presented frames for a full length movie #2 ReClock goes havoc if it is used with live tv when changing channels.My assumption would be that ReClock is trying to use the reference clock (by resampling the audio) to &quot;drive&quot; the v-sync to the sweet position. I see no benefit from it when the renderer itself is able to do the same (present video frame on the correct v-sync, before the time when directx is going to flip the backbuffer. DirectX itself will handle the). I think the v-sync correction in ReClock is something from the past, where it was required to be used to prevent the tearing (that is not an issue anymore).To get perfect video playback following would already work:1) video renderer makes sure that every single frame is presented on correct v-sync2) audio renderer generates the reference clock based on the video v-syncI see no benefit when the audio renderer tries to adjust the v-sync position. All that it should do is to make sure that reference clock runs on the same speed as the GPUs clock is running (by monitoring the v-sync, would be enough that the v-blank period is monitored, as the fine tuning of video frame presentation is done by the video renderer).</blockquote>

[QUOTE="tourettes, post: 609205, member: 10858"] Jong, do you know the logic that ReClock uses when the "correct v-sync" option is enabled? I personally don't use ReClock since #1 I have been blessed with two PCs that have such small drift between audio and GPU clocks that they cause only one or two out of time presented frames for a full length movie #2 ReClock goes havoc if it is used with live tv when changing channels. My assumption would be that ReClock is trying to use the reference clock (by resampling the audio) to "drive" the v-sync to the sweet position. I see no benefit from it when the renderer itself is able to do the same (present video frame on the correct v-sync, before the time when directx is going to flip the backbuffer. DirectX itself will handle the). I think the v-sync correction in ReClock is something from the past, where it was required to be used to prevent the tearing (that is not an issue anymore). To get perfect video playback following would already work: 1) video renderer makes sure that every single frame is presented on correct v-sync 2) audio renderer generates the reference clock based on the video v-sync I see no benefit when the audio renderer tries to adjust the v-sync position. All that it should do is to make sure that reference clock runs on the same speed as the GPUs clock is running (by monitoring the v-sync, would be enough that the v-blank period is monitored, as the fine tuning of video frame presentation is done by the video renderer). [/QUOTE]

Verification