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

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

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?

Wait wait. Reclock have a "sound pre-buffer" at 500 ms. but my test right now I see i'm using direct sound reclock.
Not wasapi exclusive. try . wait and I'll edit this post.

edit: ok reclock in wasapi exc. mode and 500 ms as "sound "pre-buffer" have a same lipsynch like MP audio renderer.
same value in directsound work fine for reclock (its default). If I set a 25 ms (the minimun) there are the clicks I heard with event driven mode in MP audio renderer. if I set 100 ms for wasapi is the correct value (lipsynch not noticeable ).
Remember that not too much reclock user speeak about wasapi I think that

 

[tourettes]

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?

Wait wait. Reclock have a "sound "pre-buffer" at 500 ms. but my test right now I see i'm using direct sound reclock.
Not wasapi exclusive. try . wait and I'll edit this post.

From Slysoft's forum / James:

No, the size of the Wasapi buffer is now independent of ReClock's pre-buffer.
You can change it via the registry (DWORD WasapiBufferSize in ms), but I believe this won't help. Default is 50ms, you can try a bigger value. Check the logfile, if the buffer size really changed.

So, you need to add a WasapiBufferSize registry setting in registry to be able to change the WASAPI buffer side. Basicly Reclock has two different buffers that you can configure. Some generic processing queue and WASAPI buffer (on device side, just like MP audio renderer has this).

HKEY_CURRENT_USER\Software\ReClock\Config\WasapiBufferSize

 

[red5goahead]

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.

No difference. the correct value still remains 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?

Wait wait. Reclock have a "sound "pre-buffer" at 500 ms. but my test right now I see i'm using direct sound reclock.
Not wasapi exclusive. try . wait and I'll edit this post.

From Slysoft's forum / James:

No, the size of the Wasapi buffer is now independent of ReClock's pre-buffer.
You can change it via the registry (DWORD WasapiBufferSize in ms), but I believe this won't help. Default is 50ms, you can try a bigger value. Check the logfile, if the buffer size really changed.

So, you need to add a WasapiBufferSize registry setting in registry to be able to change the WASAPI buffer side. Basicly Reclock has two different buffers that you can configure. Some generic processing queue and WASAPI buffer (on device side, just like MP audio renderer has this).

HKEY_CURRENT_USER\Software\ReClock\Config\WasapiBufferSize

I don't think so. changing the ReClock's pre-buffer change a lot the lipsynch.
anyway I'll try

 

[tourettes]

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.

No difference. the correct value still remains 50000 .

Too bad, since I did run out of the ideas what could be causing it - other than a possible driver bug. But the good thing is that the WASAPI buffer can be lowered to so small value that people cannot see the lip sync

And if someone says that he can detect 5 ms lip sync issue, he / she should try follong

340.29 m/s / 200 1/s = 1.70145 m - basicly if you stand 1,7 meters a way from a person who is talking towards to you should see the same lipsync "issue"

From Slysoft's forum / James:

No, the size of the Wasapi buffer is now independent of ReClock's pre-buffer.
You can change it via the registry (DWORD WasapiBufferSize in ms), but I believe this won't help. Default is 50ms, you can try a bigger value. Check the logfile, if the buffer size really changed.

So, you need to add a WasapiBufferSize registry setting in registry to be able to change the WASAPI buffer side. Basicly Reclock has two different buffers that you can configure. Some generic processing queue and WASAPI buffer (on device side, just like MP audio renderer has this).

HKEY_CURRENT_USER\Software\ReClock\Config\WasapiBufferSize

I don't think so. changing the ReClock's pre-buffer change a lot the lipsynch.
anyway I'll try

http://forum.************/showpost.php?p=182713&postcount=178 - it definitely is the same HW / driver buffer that the MP audio renderer also has. Why the normal buffer affects the lip sync in ReClock? Who knows since it is closed source, but I suspect that there is a bug in ReClock if changing that setting makes any difference to the lip sync (after all all buffer sizes should be taken into account when lip sync is considered.

 

[red5goahead]

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

No difference. the correct value still remains 50000 .

Too bad, since I did run out of the ideas what could be causing it - other than a possible driver bug. But the good thing is that the WASAPI buffer can be lowered to so small value that people cannot see the lip sync

And if someone says that he can detect 5 ms lip sync issue, he / she should try follong

340.29 m/s / 200 1/s = 1.70145 m - basicly if you stand 1,7 meters a way from a person who is talking towards to you should see the same lipsync "issue"

From Slysoft's forum / James:

So, you need to add a WasapiBufferSize registry setting in registry to be able to change the WASAPI buffer side. Basicly Reclock has two different buffers that you can configure. Some generic processing queue and WASAPI buffer (on device side, just like MP audio renderer has this).

HKEY_CURRENT_USER\Software\ReClock\Config\WasapiBufferSize

I don't think so. changing the ReClock's pre-buffer change a lot the lipsynch.
anyway I'll try

http://forum.************/showpost.php?p=182713&postcount=178 - it definitely is the same HW / driver buffer that the MP audio renderer also has. Why the normal buffer affects the lip sync in ReClock? Who knows since it is closed source, but I suspect that there is a bug in ReClock if changing that setting makes any difference to the lip sync (after all all buffer sizes should be taken into account when lip sync is considered.

the default value for Reclock was 100 ms . i have seen in its log. with 50 ms . the lipsynch improve.
any way reclock is affected by pre-buffer sound because if I set to 25 MS i go al lot of clicks. so I don't understand why James says that .
so probably this kind of parameter will be important to be a part of the new audio renderer setup like in reclock.
I never use wasapi in reclock probaby for that reason.
5ms lipsynch is good. but trust me 80 MS is really too much.

 

[tourettes]

the default value for Reclock was 100 ms . i have seen in its log. with 50 ms . the lipsynch improve.
any way reclock is affected by pre-buffer sound because if I set to 25 MS i go al lot of clicks. so I don't understand why James says that .

the buffers in Reclock are most likely following:

[pre-buffer] -> sound processing -> [wasapi buffer in audio HW]

Probably when the 1st buffer is too small the rest of the pipeline starts to run out of samples. In any case we can just wonder what happens inside ReClock - or ask from James (after all he writes the code for ReClock )

so probably this kind of parameter will be important to be a part of the new audio renderer setup like in reclock.
I never use wasapi in reclock probaby for that reason.

We cannot create similar buffer "just for fun". There is already an internal buffer / sample queue but not matter how big / small it is it wouldnt affect the MP audio renderer's lip sync at all since the buffer can be used right after there is few bytes of audio data - it doesn't have to be filled like the wasapi buffer on HW before the 1st bytes are sent to the speakers. So in that sence it wont have any affect on the lip sync (sound touch library causes small delay... approx 1 to 2 kb of audio data is buffered always inside it - but it is too minial to affect anything also it would be causing the lip sync issue on all different HWs, not jsut for one card type).

5ms lipsynch is good. but trust me 80 MS is really too much.

Yep, it will be already noticeable - but so will be the lipsync in real world if you stand approx 200 meters away from the speaker (of course it requires binoculars to spot that ).

 

[red5goahead]

Tourettes you would consider to read and follow the anti-pop thread in reclock forum. James wrote that application to disable the audio driver (only for ati hdmi I guess) when some application use and exclusive mode such as Wasapi or Asio. A a matter a fact the play-exclusive applciation often work fine and became instable for exampe when I click on folder so when a sound is played by audio card so it visibile into the mixer. that approach could help to protect the audio renderer work however with other audio card than Xonar.

 

[tourettes]

Tourettes you would consider to read and follow the anti-pop thread in reclock forum. James wrote that application to disable the audio driver (only for ati hdmi I guess) when some application use and exclusive mode such as Wasapi or Asio.

http://forum.************/showthread.php?t=41146

I guess you ment that one? It wont disable audio cards driver in any way. All that it does (based on the description) is that it will play constantly a silent stream to make sure that the drivers aren't dropping the connection to the amplifier - probably causing some few bad bytes to be send at the time

What will be disabled? It will disable itself (actually WASAPI framework or drivers - no clue which, Microsoft developers might know) as soon as there is a exclusive mode connection used - "bitstream audio, using PAP, change of speaker config, using ReClock WASAPI" those all fall into the exclusive case.

So, in short the application isn't any help for us.

A a matter a fact the play-exclusive applciation often work fine and became instable for exampe when I click on folder so when a sound is played by audio card so it visibile into the mixer. that approach could help to protect the audio renderer work however with other audio card than Xonar.

If those system sounds can cause any interference when MP Audio renderer (in exclusive mode) or the play-exclusive.exe is playing a sound then the drivers are definitely broken. Exclusive mode needs to be exclusive, no other application can or should be allowed to send anything to the audio HW (this needs to be handled by driver or the WASAPI framework. In any case applications cannot change this at all - exclusive is exclusive, it cannot be overridden with application level of control).

I would propose you to contact ASUS to sort out their drivers. I'm not able to do anything to solve those exclusive mode issues

 

[red5goahead]

If those system sounds can cause any interference when MP Audio renderer (in exclusive mode) or the play-exclusive.exe is playing a sound then the drivers are definitely broken. Exclusive mode needs to be exclusive, no other application can or should be allowed to send anything to the audio HW (this needs to be handled by driver or the WASAPI framework. In any case applications cannot change this at all - exclusive is exclusive, it cannot be overridden with application level of control).
I would propose you to contact ASUS to sort out their drivers. I'm not able to do anything to solve those exclusive mode issues

For me is not a problem. Probably also Ati drivers have that kind of issue and so explain why the James application. I hope for us be limited to Asus and Ati hdmi.
Let me know, if I play a file with wasapi exclusive mode and I start foorbar on directsound I shouldn't hear anything else than audio played in MP? Am I right?

 

[tourettes]

For me is not a problem. Probably also Ati drivers have that kind of issue and so explain why the James application. I hope for us be limited to Asus and Ati hdmi.

The ATI "pop" issue that James' tool is fixing is a different one that you are seeing with Xonar. ATI's issue is that you would hear noise when stoping or starting playback where as Xonar corrupts the stream during the playback when some system sound for example is tried to play. Two completely different issues (and the ATI issue is fixed in latest drivers, or maybe even with the 10.6).

Let me know, if I play a file with wasapi exclusive mode and I start foorbar on directsound I shouldn't hear anything else than audio played in MP? Am I right?

Yes, if some (no matter what) application has an exclusive mode WASAPI stream in use not a single different application is allowed to make any sound.

Just think how it would corrupt the encoded bitstream if you would be bitstreaming DTS-MA track for example? All you would hear in the speakers would be pure noise if something is mixed into a encoded stream.