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

[edterbak]

Xonar user here as well.
Im getting the same results as red5. When I see irratic multipliers, I always see faulty actual fps numbers like 24.6 or 25.8. Mostly I play 1:1 material
23.9fps>23.9hz 24fps>24hz 50/50 and 60/60.
no clear trend visible as well. Got the same result with WMA 5.1 file (dark knight) and with simple stereo MP3 audio.

I will post a log with the above file, and using wasapieventmode1 exclusive1 hwclock1 in regs.

 

[disaster123]

AW: MediaPortal Audio renderer - better video playback quality

Are here also other people who experience the following behaviour.

I'm watching a recording - volume is OK - then after skipping through the first commercials volume is also OK - then watching the show again the volume is lower than before. Then after the next commercial the same again. Problem i've to higher the volume again and again... (seems to only happen when sound format changes between show and commercial)

 

[edterbak]

Tourettes,

Here are my logs. Probably a duplo with Red5.

 

[tourettes]

I will post a log with the above file, and using wasapieventmode1 exclusive1 hwclock1 in regs.

Could you post a log with wasapieventmode = 0? Since isn't Xonar playing garbage when it is 1?

 

[tourettes]

Re: AW: MediaPortal Audio renderer - better video playback quality

I'm watching a recording - volume is OK - then after skipping through the first commercials volume is also OK - then watching the show again the volume is lower than before. Then after the next commercial the same again. Problem i've to higher the volume again and again... (seems to only happen when sound format changes between show and commercial)

Please check with graphedit that the MP audio renderer is always used (some renderer could do some normalization for the audio - MP audio renderer itself is not touching the volume level at all, there is just no code for such ). Also provide a log an TS file that can be used to reproduce the issue.

 

[tourettes]

Anyway , yes it's a luck that both screen shots show it as 1.002xxxxx. the multiplier is always erratic . No change after 4000 frames.

Here is my log.

14-10-2010 22:47:18.524 [ 1020] HW clock diff: 53333 QPC diff: 50539
14-10-2010 22:47:18.529 [ 1020] HW clock diff: 53333 QPC diff: 49587
14-10-2010 22:47:18.534 [ 1020] HW clock diff: 53334 QPC diff: 49830
14-10-2010 22:47:18.539 [ 1020] HW clock diff: 53333 QPC diff: 49879
14-10-2010 22:47:18.544 [ 1020] HW clock diff: 53333 QPC diff: 50473
14-10-2010 22:47:18.549 [ 1020] HW clock diff: 53334 QPC diff: 50100
14-10-2010 22:47:18.554 [ 1020] HW clock diff: 53333 QPC diff: 50561
14-10-2010 22:47:18.559 [ 1020] HW clock diff: 26667 QPC diff: 48916
14-10-2010 22:47:18.564 [ 1020] HW clock diff: 53333 QPC diff: 50223
14-10-2010 22:47:18.569 [ 1020] HW clock diff: 53333 QPC diff: 50042
14-10-2010 22:47:18.574 [ 1020] HW clock diff: 53334 QPC diff: 49856
14-10-2010 22:47:18.579 [ 1020] HW clock diff: 53333 QPC diff: 50061
14-10-2010 22:47:18.584 [ 1020] HW clock diff: 53333 QPC diff: 49948
14-10-2010 22:47:18.589 [ 1020] HW clock diff: 53334 QPC diff: 50216
14-10-2010 22:47:18.594 [ 1020] HW clock diff: 53333 QPC diff: 51618
14-10-2010 22:47:18.599 [ 1020] HW clock diff: 26667 QPC diff: 48036
14-10-2010 22:47:18.604 [ 1020] HW clock diff: 53333 QPC diff: 50071

Xonar does it's own thing again

First of all the drivers are just lying to us, 53333, 53334 is much too accurate to be correct. I would say it is hundred times too accurate what the audio renderer's polling mode could be having for the querying accurancy (timer isn't that accurate).

2nd issue that can be spotted is that the driver is telling it is advancing approximately on 1.0666...x speed when compared to the system clock (53333 / 50000). This cannot be true especially since the 26667 happens as well to compensate it. Looks like the driver side is not actually knowing the exact playback position on the HW buffer and makes up the data by some algorithm and then corrects it when the HW buffer information is available (26667 is the correction phase). I wouldn't want to create any workaround for badly behaving drivers (it wont ever be as good as the correctly working driver, also I have currently no clue how to patch and still keep the currently correctly behaving HW ok).

Could you test 50 ms, 500 ms buffers as well with the logging?

Also if there is no drifting with the HW based reference clock not used case it should be good enough as a overcoming period when ever ASUS decides to fix their drivers.

 

[red5goahead]

Anyway , yes it's a luck that both screen shots show it as 1.002xxxxx. the multiplier is always erratic . No change after 4000 frames.

Xonar does it's own thing again

Imho is that the audio renderer is becoming too much subordinate by the hardware. That will could be a problem when much user will use it. Hardware is as it is. But you know that.

 

[tourettes]

Anyway , yes it's a luck that both screen shots show it as 1.002xxxxx. the multiplier is always erratic . No change after 4000 frames.

Xonar does it's own thing again

Imho is that the audio renderer is becoming too much subordinate by the hardware. That will could be a problem when much user will use it. Hardware is as it is. But you know that.

Fact is that we need to make constantly workarounds for broken drivers. Currently Nvidia has acted quite nicely and fixed almost all the issues on WASAPI side (maybe they did see the nagging I did post ).

2nd fact is that the Xonar has completely broken drivers what comes to the audio clock. It is almost impossible to create any sane workaround for that kind of issue. Just think about a stopwatch that would behave the same way. First it runs too fast and then it almost stalls for a brief period of time to let the universe to catch it.

Attached graph shows the own realm where Xonar's drivers live and how the time line is twisted. Red is the performance counter value that the driver gives (real time) and the blue is the playback position. As you can see it will "play" faster speed than the clock and then it will stall to slower speed to allow the correct stream time to be catched (I'm 101% sure that this is not the reality how HW works, but instead it is just lazy driver developers who haven't implemented the WaveRT drivers properly - after all the audio doesn't act weird with Xonar when the polling based mode is used).

 

[red5goahead]

Fact is that we need to make constantly workarounds for broken drivers. Currently Nvidia has acted quite nicely and fixed almost all the issues on WASAPI side (maybe they did see the nagging I did post ).
2nd fact is that the Xonar has completely broken drivers what comes to the audio clock. It is almost impossible to create any sane workaround for that kind of issue. Just think about a stopwatch that would behave the same way. First it runs too fast and then it almost stalls for a brief period of time to let the universe to catch it.

Your work was amazing . Certainly the Xonar hardware and its driver are not very good. I agree about that. I'm not worried about this issue but I'm worried for the audio renderer because the hw on market are as they are so when much users will try it will be not an option to tell them to change the hardware even for Xonar DX, D2 etc, audio cards that are a top choice for quality.
Obviously we hope this kind of issues are limited to these Asus products.

thanks again

Now I'll try the issue with the Realtek onboard on my P5K mobo.

 

[edterbak]

Tourettes,

Could you make a clear, correct and technical description of the problem with the Xonar drivers. I want to post the issue to the asus tech team, but ofcourse I dont understand a thing you were just talking about with Red5
Hope this gets solved quick.

Thanks