MediaPortal Audio renderer - better video playback quality (2 Viewers)

[tourettes]

If you do another detailed log (with the accurate clock and multiplier) I'll push the numbers through see what happens. Do you have Excel - and what version?

Please find the logs attached. _with_mul.log is the one where "*" is used and the normal is the "/".

 

[davidf]

That's good because the last logs had over 64K samples and you can put that in 2003.

As you can see it is quite possible to write broken reference clock code that will behave just good enough on some systems.

To be quite honest there are still errors in there. The increase in accuracy has just made sure that SUM(errors)=0, with the lower accuracy the error was always positive. The big remaining error is that you are not taking into account the sample times of the stuff going through SoundTouch so there is a period when EVR has asked for a speed up and you aren't doing it and a period when it has asked to stop speeding up and you still are - that's the whole PI1+UP1 thing. Fortunately the SUM(Error) for that should be 0 as well.

I'm sure you could craft a scenario where this would all go wrong but over a period of time it should work out fine.

I haven't ever had this hard decission to be made with one char

Easiest way to say for sure is answer 1 question:

Using nothing on the HTPC i.e. no audio renderer - which way does the drift go: sound first or sound after?

Maybe Owlsroosts reads this thread and tells us right away what goes nuts inside the EVR presenter

You might want to give him a shout when you see this:

Mult
Total adjustment requested by EVR -363447
Forward Adjustments 0
Backwards Adjustments 7422
Multiplier adjustment 75782

Div
Total adjustment requested by EVR 162762.1485
Forward Adjustments 3604
Backwards Adjustments 0
Multiplier adjustment 79467.25431 (would be downwards)


i.e. when you increase the clock EVR slows it down.

Try amusing yourself by speeding up and slowing down the sound by 1.00005885 (rough estimate of the mult) - EVR can't detect that.

 

[tourettes]

As you can see it is quite possible to write broken reference clock code that will behave just good enough on some systems.

To be quite honest there are still errors in there. The increase in accuracy has just made sure that SUM(errors)=0, with the lower accuracy the error was always positive. The big remaining error is that you are not taking into account the sample times of the stuff going through SoundTouch so there is a period when EVR has asked for a speed up and you aren't doing it and a period when it has asked to stop speeding up and you still are - that's the whole PI1+UP1 thing. Fortunately the SUM(Error) for that should be 0 as well.

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.

• 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
• Resampling error is then send to the reference clock calculation code - and the error is slowly "injected" into the reference clock results

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.

I'm sure you could craft a scenario where this would all go wrong but over a period of time it should work out fine.

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

I haven't ever had this hard decission to be made with one char

Easiest way to say for sure is answer 1 question:

Using nothing on the HTPC i.e. no audio renderer - which way does the drift go: sound first or sound after?

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).

 

[tourettes]

You might want to give him a shout when you see this:

Mult
Total adjustment requested by EVR -363447
Forward Adjustments 0
Backwards Adjustments 7422
Multiplier adjustment 75782

Div
Total adjustment requested by EVR 162762.1485
Forward Adjustments 3604
Backwards Adjustments 0
Multiplier adjustment 79467.25431 (would be downwards)

i.e. when you increase the clock EVR slows it down.

I think EVR is working correctly (Also we shouldn't blame Owlsroost for the bugs in EVR's adjustment request code - I did write it based on Seidelin's math).

EVR presenter cannot do anything else than try to use the adjust so that the v-sync position will stay in correct place. If presentation point is faling down (v-sync position is increasing) EVR just asks the audio renderer to slow down the speed of the reference clock. And if the frames are getting too early it will ask the speed to be increased.

7422 vs 3604 is approx the double when taking into account the reality (v-sync startup point could be anything in either of those cases). Double should be correct since if the direction ( * or / ) is changed then the correction that is required would be twice as big.

 

[davidf]

You shouldn't need to take anything else into account - the errors will cancel each other out (or will once you figure out why EVR is trying to compensate for your clock correction). I had done the tossing a coin explanation - but deleted it. Just think about tossing a coin 10 million times with head a positive error and tails a negative error. It certainly would do no harm to correct it if you can though. You'd need to add log info about it as there's nothing I could use to estimate in the current logs. The only thing I can tell you is that in the * one there were 2 (long) uses of the adjustment and in the / one there were 24 (short) uses.

The thing to worry about is why the small correction is causing EVR to try and correct it's sync in the opposite direction, as I said you could adjust the audio speed by mult (same arguments for * and / ) which wouldn't be detectable by EVR and would produce the same results.


I'll have to go and see if any of my machines has IIS installed as the excel sheet is rather large.

Actually thinking about it then the mult makes sense as it made the adjustments at the beginning and then stopped (I've had to page through the thing to find that out). Div doesn't as it had to constantly readjust as it was drifting out (or thought it was). Guess that tells you which one is correct. Would be interesting to know what the numbers would be if you ignore the AV drift in the clock.

I think EVR is working correctly (Also we shouldn't blame Owlsroost for the bugs in EVR's adjustment request code - I did write it based on Seidelin's math).

I wasn't thinking of blaming him - I was interested in the effect, and I'm betting that he has played with the code and seen the same effects.

 

[tourettes]

You shouldn't need to take anything else into account - the errors will cancel each other out (or will once you figure out why EVR is trying to compensate for your clock correction). I had done the tossing a coin explanation - but deleted it. Just think about tossing a coin 10 million times with head a positive error and tails a negative error. It certainly would do no harm to correct it if you can though. You'd need to add log info about it as there's nothing I could use to estimate in the current logs. The only thing I can tell you is that in the * one there were 2 (long) uses of the adjustment and in the / one there were 24 (short) uses.

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 processed
2) 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 processed

In 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 )

The thing to worry about is why the small correction is causing EVR to try and correct it's sync in the opposite direction, as I said you could adjust the audio speed by mult (same arguments for * and / ) which wouldn't be detectable by EVR and would produce the same results.

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).

 

[tourettes]

Actually thinking about it then the mult makes sense as it made the adjustments at the beginning and then stopped

If I remember correctly the logs were from right after the startup (not 100% sure thou). At that point the EVR presenter will "drive" the presentation position to the correct place. This is done with same 1.003 / 0.997 adjustment value, so it could take a while until it is done. For example with 25 fps movie:

- time per frame 40 ms
- target position 0.25 -> 10 ms
- worst v-sync position 0.99999 -> 40 ms
- distance to "crawl" -> 30 ms (direction is always the same to reduce the stuttering while moving v-sync... off topic this time )

max time 10 seconds?

 

[davidf]

You shouldn't need to take anything else into account - the errors will cancel each other out (or will once you figure out why EVR is trying to compensate for your clock correction). I had done the tossing a coin explanation - but deleted it. Just think about tossing a coin 10 million times with head a positive error and tails a negative error. It certainly would do no harm to correct it if you can though. You'd need to add log info about it as there's nothing I could use to estimate in the current logs. The only thing I can tell you is that in the * one there were 2 (long) uses of the adjustment and in the / one there were 24 (short) uses.

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 processed

And will also always have requested the adjustment after a block has started, so resampling will not happen on that part.

2) 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 processed

In 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 )

But you were playing a 1:1 and correcting so the measured rate was exactly correct when measured. I was actually wondering if there was a difference from an EVR point of view between speeding up the clock and slowing down the sound rate. Both will have the effect of correcting the AV drift, but only speeding up the clock will be visible to EVR.

Actually, if you want to know if you need to correct the sound samples then just log the speedup slow down requests. The number and frequency should tell you, as if there are very few then you've got it right i.e. sound + video are happening at the right times.

The thing to worry about is why the small correction is causing EVR to try and correct it's sync in the opposite direction, as I said you could adjust the audio speed by mult (same arguments for * and / ) which wouldn't be detectable by EVR and would produce the same results.

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).

Again on the audio slow vs time quick

Slow the audio: the reference clock remains at the same speed and on a 1:1 v-sync should stay in position (assuming super accurate clock and accurate calculation of bias)
Speed up the clock: the clock works a bit faster and so the v-sync position will drift as 20ms will become 19.9999 and the real v-sync won't change.

Or am I mistaken (it is very late).

 

[davidf]

It's now very early and I have a better way of describing it:

The sound is playing at slightly the wrong rate on the audio hardware because of the drift.
You alter the clock to take this into account, the sound is still playing at the wrong rate, so the EVR should correct it a lot to end up with the sound playing at the correct rate on average (it's using bias to match the clock to the refresh rate of the display).
If you alter the audio rate then the sound should play at the correct rate so the EVR won't need to correct much, if at all. i.e. If you set the adjustment for soundtouch as adjustment/mult (or adjustment * mult - the opposite of the correct clock adjustment) then this will make the audio hardware play the sound at exactly the rate it should. Again this is relative to the EVR presenter which is already corrected by the bias.

 

[Henkie Flits]

Tourettes, here are the logs and the setting screens using the SAF5 installed decoders and settings. I couldn't find a Mixer setting screen.