Reply to thread

Message: <blockquote data-quote="tourettes" data-source="post: 662860" data-attributes="member: 10858">First of, thanks for spotting the delta sum error we had, I wouldn't have spotted in a long time. Might have taken who knows how long...The adjustment error sum is still there. I have been trying to avoid touching that arion's proposal and turning that into real code - it is really complex and relies on the WASAPI device position query that is currently behaving not so good (seems to work nicely if it is done only from the renderer thread, but reference clock is queried from whole bunch of different components and even bigger amount of different threads).But I think it is good that I haven't taken it into use yet. After one beer all seems now much more cleaner and I have much more simpler aproach to handle the error what comes from the EVR v-sync adjustment requests. We just need to treat those in the same way as the delta error is handled. Arion's approach is much more presice that we need - we aren't interested in the exact time when the "error" happens. we just want to know how much there is error / diff to be compensated.<ul> <li data-xf-list-type="ul"> We know exact amout of the resampling the adjustment causes - both duration and the multiplier are both known. This should give us the amount of the total error we are creating. One sample in, duration * adjustment - duration amount of error is generated <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile    :)" loading="lazy" data-shortname=":)" /></li> <li data-xf-list-type="ul"> Resampling error is then send to the reference clock calculation code - and the error is slowly "injected" into the reference clock results</li> </ul>Does the "Excel" tell if that is nescessary? Mainly can you see how much the dev PC has error from the adjustments that piles up in 2 hours? If less than 10 ms then we could ignore it, but otherwise I think we need to take care of it.Yep, worst case scenario is not that good for the eyes. On 1000 adjustments, everyone taking 1000 ms and done for the same direction on such events that the audio renderer's reference clock is not queried during the 1000 ms time... hell would break loose - drifting would be around 3000 ms <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile    :)" loading="lazy" data-shortname=":)" /> No drifting happens at all Default DirectSound Audio Renderer. Also seems that the current code produces same results. And the best part is that even "*" seems to work on the dev PC now. It was something specific for one DVD where the stuttering appeared (of course I haven't been testing enough to be sure - only 45 minutes).</blockquote>

Verification