Reply to thread

Message: <blockquote data-quote="davidf" data-source="post: 656953" data-attributes="member: 19484">I tried that first and ended up removing it as it didn't do much, I ended up placing it in scheduler thread to test the reliability.  That was quite interesting when I gave it a bit of testing last night... What I got be to be stable enough to test:During polling the earliest sample time is calculated - this results in resetting the timer with about half the required delay.  This resulted in multiple cycles before correct point was hit i.e. 20ms to time became 10 which next cycle becomes 5 becomes 2.5 etc.After a few failed attempts and lots of stuttering pictures I did the obvious think and put the waitable timer just after this calculation to kick in for any delays over 1ms with a minimum timer of 0.4ms and a max of 20ms.  I also took 1.6ms off the delay to ensure it didn't overshoot.  The existing polling was left as it also undershot.  (I suspect that if the three threads were brought down to 1 where the mixer queue was checked after a sample event then the timer would work better as the number of threads under MCSS seriously affects the accuracy i.e. pull all possible samples after a render or drop.)  Scrap that - the errors are based on machine load so it doesn't seem to matter what you do. First test BBC News with ticker on bottom (SD) with PDVD9 and MS codecs:Perfectly stable with smooth ticker - no stuttering with Audio Renderer working.  This was with all logging turned off to reduce the possibility of side effects. Second test BBC HD (1440x1080? which is a squashed HD picture used by the BBC) using MS Codec:Stable picture but audio dropout for 5 seconds (this is due to falsely reported framerates from the codec as Tourettes spotted some time ago).  And now the strange bits (although I can probably guess what's up for some of them).  When viewing the guide i.e. small TV picture, it stuttered and the picture froze returning to full screen continued perfect playback.  I guess the 1.6ms delay needs some adjustment feedback to set itself correctly on the clock accuracy at that point in time because the polling is still needed in the event of a "miss" or the timer needs to be put in a loop.  I didn't try to detect too much delay because this was the umpteenth attempt and I didn't expect to get a better result than stuttering to be honest. Next HD test BBC HD (1440i?) using PDVD Codec:As before but no audio dropout, after 30 seconds the picture stopped being updated. I guess something very bad happened and happened again when I retried.  I think sound kept going.  As I had logging turned off that's all I can tell you with certainty. I think some of the earlier issues I had were caused by the fact that the scheduler thread has multiple input points i.e. timer and new sample so you can't act any sooner due to the scrubbing/late frame and other logic in the presenter.  I suspect that a nice way to do it would be to call the routine every 2ms or so to allow samples to be dropped/taken form the mixer in the event of a 16x or 32x playback and then use the timer to wait if within 2ms of a presentation time.  This would allow a single thread to do all the work and possibly get a better degree of accuracy on the timer (possibly not as the timer accuracy decreases with load).  I'll try that next after I get back from holidays.  If I get a chance tonight I'll post the patch/code as I'd be interested to see how it would perform on better hardware - there is a 4670 upstairs but it'll be hard for me to test with it for a while (long story).</blockquote>

Verification