Reply to thread

Message: <blockquote data-quote="tourettes" data-source="post: 662876" data-attributes="member: 10858">Coin analogy is not 100% suitable (althou in practice I would assume the results are quite much the same - errors canceling each other). We most likely are having weighted coin in the resampling phase. Resampler is probably making some systematic error (and causing therefore a small drifting). The systematic error would be coming from the fact that the resampler is not working in real time, but instead it is faster, so it will probably manage to resample too much data for two reasons:1) resampling is done always on whole block. EVR will always request the adjustment canceling during such block. This will always give us extra data that gets processed2) since resampling is done as fast as CPU and output sample queue drain can eat the samples there are times when extra data can be also processedIn theory the drifting is always on one direction - and EVR should be favoring the correction to one direction (hickups etc. arent the main reason for the correction) because the audio vs. GPU clock multiplier is constant (of course small fluctuation happens but it shoulnd't be as big as the real difference between the clocks or the HW is really bad or really good <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile    :)" loading="lazy" data-shortname=":)" />)Are we sure that it is just not the v-sync correction that the EVR presenter does? Since the correction is done only by asking the reference clock to be modified (v-sync itself cannot be moved so we have to move the arrow instead of the target). To me it looks like it is working as it should - EVR needs to react to the reference clock values (not * or / is correct from the EVR's point of view since we wont have 1:1 match with the audio and video clocks).</blockquote>

Verification