home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Development
General Development (no feature request here!)
MediaPortal Audio renderer - better video playback quality
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="davidf" data-source="post: 661656" data-attributes="member: 19484"><p>I think the drifting is something basic (at least it will be after you figure it).</p><p></p><p>Logically there isn't too much too it:</p><p>1. Real refresh rate doesn't match source refreshrate : catered for by bias</p><p>2. Synching at wrong point in refresh : uses 1.003,1,0.997 adjustment to move vsynch position should be less than 10ms or so total.</p><p>3. Clock drift - the unknown. For you 173 ms per hour from the logs you sent based on multiplier. Does that sound like what you are seeing with the constant drift or is it out by a factor?</p><p></p><p>Single clock solution and variables:</p><p></p><p>possible errors in presenter refresh calcs : unlikely as 6 samples from 8 used, possible error low (would need to be out by more than 2000 nano seconds for 5 ms drift)</p><p>moving synch point - should be ignoreable as will be under 1 frame (good test as shouldn't be noticeable if drop it from the equation). However if this isn't working properly then it will cause drift.</p><p>clock drift - turns out to be quite hard as this is where it all happens together <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" /></p><p></p><p>Maximum allowed multiplier error for 1 frame per hour synch loss at 50fps : 1.0000055. 1.0000014 for 5ms. This is a high level of accuracy given the variance seen in the logs, the variance is above this even after 30 seconds of samples.</p><p></p><p>Possible correction mechanisms / debug mechanisms</p><p></p><p>Stream time? Both parts should know where they are in the stream or be able to provide a reasonable approximation - is this true? Would something else be need to determine stream position.</p><p>Can't think of much else. Would be really useful to know the actual drift rate on a machine to validate the calculations.</p><p></p><p></p><p>Problem How to validate accuracy of calculations?</p><p>HwCLock AudClock calculated_Clock Bias Adjustment AudClockDrift AudioStreamMultiplier StreamPosition </p><p></p><p>HwCLock - available (not contiguous across threads? or is this a result of logging) I'll check this statement when I go back home.</p><p>AudClock - available but not contiguous (monotonic)</p><p>calculated_Clock - a result of the adjustment figures</p><p>Bias - Calculated as a result of the framerate</p><p>Adjustment (0.997,1,1.003) - should only be used for initial adjustment to vsync then have a net of zero (very minor corrections)</p><p>AudClockDrift - calculated by taking drift between harware and Audio Clocks</p><p>AudioStreamMultiplier - Bias * Adjustment * AudClockDrift</p><p>Stream Position - Current Stream Position</p><p></p><p>At any point audio consumed should = nFramesProcessed*streamFrameRate + time since last paint</p><p>both of these should be available (possibly not at the same time) and could be used to limit the potential errors which are present. All the calculations are proactive (trying to anticpate the problem) and something is needed to be reactive (react to errors is the calculations). If the calculations are accurate then the reactive should not occur, the reactive could limit errors to a few ms (I still reckon something obvious is wrong as the drifting seems too high but this might be due to scrubbing in the first few seconds)</p><p></p><p>Perfect Playback:</p><p>1 Frame per display Refresh</p><p>Audio Resampled at AudioStreamMultiplier rate OR calculated_Clock used in place of AudioClock</p><p></p><p>This won't work for TV if framerate != displayrate</p><p></p><p></p><p>Another silly question as I've not looked at the renderer code why do the threads each appear to have there own multiplier (last number as I put it in Excel)?</p><p></p><p></p><p>[Code]</p><p>28/09/2010 22:38:34.685 [1408] 1.000470</p><p>28/09/2010 22:38:34.685 [1408] 1.000473</p><p>28/09/2010 22:38:34.686 [fa0] 1.000048</p><p>28/09/2010 22:38:34.686 [1408] 1.000483</p><p>28/09/2010 22:38:34.686 [1408] 1.000486</p><p>28/09/2010 22:38:34.686 [1408] 1.000488</p><p>28/09/2010 22:38:34.689 [fa0] 1.000048</p><p>[/Code]</p><p>qpc vs hw overall = 1.00005933 or 20ms total adjustment over 30 seconds</p><p></p><p></p><p>BTW v13 has sudden synch issues.</p></blockquote><p></p>
[QUOTE="davidf, post: 661656, member: 19484"] I think the drifting is something basic (at least it will be after you figure it). Logically there isn't too much too it: 1. Real refresh rate doesn't match source refreshrate : catered for by bias 2. Synching at wrong point in refresh : uses 1.003,1,0.997 adjustment to move vsynch position should be less than 10ms or so total. 3. Clock drift - the unknown. For you 173 ms per hour from the logs you sent based on multiplier. Does that sound like what you are seeing with the constant drift or is it out by a factor? Single clock solution and variables: possible errors in presenter refresh calcs : unlikely as 6 samples from 8 used, possible error low (would need to be out by more than 2000 nano seconds for 5 ms drift) moving synch point - should be ignoreable as will be under 1 frame (good test as shouldn't be noticeable if drop it from the equation). However if this isn't working properly then it will cause drift. clock drift - turns out to be quite hard as this is where it all happens together :-) Maximum allowed multiplier error for 1 frame per hour synch loss at 50fps : 1.0000055. 1.0000014 for 5ms. This is a high level of accuracy given the variance seen in the logs, the variance is above this even after 30 seconds of samples. Possible correction mechanisms / debug mechanisms Stream time? Both parts should know where they are in the stream or be able to provide a reasonable approximation - is this true? Would something else be need to determine stream position. Can't think of much else. Would be really useful to know the actual drift rate on a machine to validate the calculations. Problem How to validate accuracy of calculations? HwCLock AudClock calculated_Clock Bias Adjustment AudClockDrift AudioStreamMultiplier StreamPosition HwCLock - available (not contiguous across threads? or is this a result of logging) I'll check this statement when I go back home. AudClock - available but not contiguous (monotonic) calculated_Clock - a result of the adjustment figures Bias - Calculated as a result of the framerate Adjustment (0.997,1,1.003) - should only be used for initial adjustment to vsync then have a net of zero (very minor corrections) AudClockDrift - calculated by taking drift between harware and Audio Clocks AudioStreamMultiplier - Bias * Adjustment * AudClockDrift Stream Position - Current Stream Position At any point audio consumed should = nFramesProcessed*streamFrameRate + time since last paint both of these should be available (possibly not at the same time) and could be used to limit the potential errors which are present. All the calculations are proactive (trying to anticpate the problem) and something is needed to be reactive (react to errors is the calculations). If the calculations are accurate then the reactive should not occur, the reactive could limit errors to a few ms (I still reckon something obvious is wrong as the drifting seems too high but this might be due to scrubbing in the first few seconds) Perfect Playback: 1 Frame per display Refresh Audio Resampled at AudioStreamMultiplier rate OR calculated_Clock used in place of AudioClock This won't work for TV if framerate != displayrate Another silly question as I've not looked at the renderer code why do the threads each appear to have there own multiplier (last number as I put it in Excel)? [Code] 28/09/2010 22:38:34.685 [1408] 1.000470 28/09/2010 22:38:34.685 [1408] 1.000473 28/09/2010 22:38:34.686 [fa0] 1.000048 28/09/2010 22:38:34.686 [1408] 1.000483 28/09/2010 22:38:34.686 [1408] 1.000486 28/09/2010 22:38:34.686 [1408] 1.000488 28/09/2010 22:38:34.689 [fa0] 1.000048 [/Code] qpc vs hw overall = 1.00005933 or 20ms total adjustment over 30 seconds BTW v13 has sudden synch issues. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Development
General Development (no feature request here!)
MediaPortal Audio renderer - better video playback quality
Contact us
RSS
Top
Bottom
