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

[tourettes]

But there are a lot of clicks . The sound is not good.

Disable:

04-09-2010 12:45:25.288 [ 248] WASAPIUseEventMode: 1

That was previously tested as non working for Xonar (if I remember correctly).

 

[red5goahead]

But there are a lot of clicks . The sound is not good.

Disable:

04-09-2010 12:45:25.288 [ 248] WASAPIUseEventMode: 1

That was previously tested as non working for Xonar (if I remember correctly).

Yes. It work but with the usual lipsynch issue we got disabling event driven mode I guess.

edit: I calculate a delay about 60 ms (audio must be haste for 60 ms, -60 value in ffdshow delay edit control)

 

[mironicus]

AW: MediaPortal Audio renderer - better video playback quality

Oh, I am sorry. I had this issue with the stuttering and the FFDShow Audiodecoder with the MPAudioRenderer disabled.

However the new dshowhelper.dll was enabled and working with DirectSound and the videos were stuttering with the Jitter Correction turned on (playing 23,976 fps at 23,976 Hz). Dshowhelper reported some dropped frames. After turning if off the files were running smoothly again.

Also interesting: The frame drops does not appear randomly, they are fixed and appear at the same video position again and again. I noticed that behaviour on a slow camera moving up scene and the video dropped frames always at the same position - even after dozens of repeatings and skipping back to the same scene again!

However after turning off the Jitter correction in FFDShow audio decoder this problem does not appear anymore (also after selecting another audio decoder).

UPDATE: I tried to reproduce the problem I had last night but how funny... I can't! The video is running smoothly with the jitter correction turned on and off. However the impression I have is still the same that turning this feature off might be better to prevent those random appearing stutters.

 

[tourettes]

Yes. It work but with the usual lipsynch issue we got disabling event driven mode I guess.

edit: I calculate a delay about 60 ms (audio must be haste for 60 ms, -60 value in ffdshow delay edit control)

Event driven mode wont work with Xonar until someone fixes the drivers (play-exclusive.exe must play all kind of WAV files with no dropped data / stuttering)

Does the lipsync go away if you use skip steps to seek a different postition?

Does the lipsync get bigger smaller if you change the DevicePeriod value in registry? Default is 50 ms, so it would fit nicely into that 60 ms window (after all 10 ms difference in lip sync is quite impossible to see since the difference between different video frames is already bigger). Some values to try:

50000 equals to 5 ms
1000000 equals to 100ms
5000000 equals to 500ms

I'll have to play around with big buffer value to see if I can reproduce that lipsync issue (it could be driver or audio renderer issue, mostlikely the later one).

 

[red5goahead]

Yes. It work but with the usual lipsynch issue we got disabling event driven mode I guess.

edit: I calculate a delay about 60 ms (audio must be haste for 60 ms, -60 value in ffdshow delay edit control)

Event driven mode wont work with Xonar until someone fixes the drivers (play-exclusive.exe must play all kind of WAV files with no dropped data / stuttering)

Does the lipsync go away if you use skip steps to seek a different postition?

Does the lipsync get bigger smaller if you change the DevicePeriod value in registry? Default is 50 ms, so it would fit nicely into that 60 ms window (after all 10 ms difference in lip sync is quite impossible to see since the difference between different video frames is already bigger). Some values to try:

50000 equals to 5 ms
1000000 equals to 100ms
5000000 equals to 500ms

I'll have to play around with big buffer value to see if I can reproduce that lipsync issue (it could be driver or audio renderer issue, mostlikely the later one).

Firstable forget about last post because lipsynch does not become worst so It start with about -75 ms (huge) when devicePeriod is equal to 500.000 (50 MS) but does not degrade (tested for 15 minutes)

you ask me : does the lipsync go away if you use skip steps to seek a different postition?
not but sometimes become worst some times back to intial situation.

with 50000 value the start lipsynch goes was and the lipsysnch become perfect so yes the deviceperiod is very important for that issue. Imho this is not a good news.

 

[tourettes]

Firstable forget about last post because lipsynch does not become worst so It start with about -75 ms (huge) when devicePeriod is equal to 500.000 (50 MS) but does not degrade (tested for 15 minutes)

I cannot reproduce the lipsync issue with NVIDIA HDMI (cannot test with SPDIF since I cannot get picture to monitor with the HDMI in that case ). Even 500 ms buffer give correct lipsync. Based on that I would say it is something in the Xonar's drivers (they have been already proven quite buggy )

Also didn't you say that Reclock has lipsync issue as well? That would definitely point into the driver direction.

with 50000 value the start lipsynch goes was and the lipsysnch become perfect so yes the deviceperiod is very important for that issue. Imho this is not a good news.

I guess that could be the only solution with Xonar, lower the device buffer period as small as you want the maximun amount of possible lipsync to be - 10 ms could be a good choise since it is already two times more forgiving for the possible sample dropouts (CPU will be filling the buffer two times slower speed).



Could others try as well the lipsync issue with exclusive mode on and event driven mode off?

 

[tourettes]

with 50000 value the start lipsynch goes was and the lipsysnch become perfect so yes the deviceperiod is very important for that issue. Imho this is not a good news.

I guess that could be the only solution with Xonar, lower the device buffer period as small as you want the maximun amount of possible lipsync to be - 10 ms could be a good choise since it is already two times more forgiving for the possible sample dropouts (CPU will be filling the buffer two times slower speed).

I think there is one thing we could try. We might need to "flush" the buffers just right before the audio stream is started. Althou this could shift the issue to all other cards. Need to test a bit.

 

[red5goahead]

Also didn't you say that Reclock has lipsync issue as well? That would definitely point into the driver direction.

Reclock work fine with its default values as MP audio renderer with 5 Ms (50000)

 

[tourettes]

Also didn't you say that Reclock has lipsync issue as well? That would definitely point into the driver direction.

Reclock work fine with its default values as MP audio renderer with 5 Ms (50000)

Do you know what the default value is? Also could you check the Reclock, is it behaving the similar way when changing the wasapi buffer size?

 

[tourettes]

with 50000 value the start lipsynch goes was and the lipsysnch become perfect so yes the deviceperiod is very important for that issue. Imho this is not a good news.

I guess that could be the only solution with Xonar, lower the device buffer period as small as you want the maximun amount of possible lipsync to be - 10 ms could be a good choise since it is already two times more forgiving for the possible sample dropouts (CPU will be filling the buffer two times slower speed).

I think there is one thing we could try. We might need to "flush" the buffers just right before the audio stream is started. Althou this could shift the issue to all other cards. Need to test a bit.

Xonar a/v sync test binary. Most likely it wont make any difference.