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

[tourettes]

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

I would be very glad if the audio renderer and the modified dshowhelper.dll could be added to the svn.

There are already two branches now. The 1.20 does have those new changes from ajp that are also in beta state and does also have some bugs. The audio renderer should be added too so you'll can make your changes and improvements within the svn.

My understanding is that the v0037 version of the dshowhelper will be in MP 1.2.0

Yep, that is what I understand as well (or it might be v0038 who knows ) But in any case it is intented to get that great EVR presenter improvement(s) into 1.2.0 - thanks goes to Tony and all the testers who have been doing a really great job on that area.

 

[davidf]

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

Also as you can see from this thread the audio renderer receives currently really minimal testing interest. With such it really isn't possible to even think about having the 1.2.0 containing the audio renderer.

I don't see the logic of not having it in 1.2.0 as the the MP Audio Renderer does not have to be chosen, forcing the MP audio renderer into the pipeline would be a different story.

After playing with it a lot I now don't use it for TV as my hardware clocks seem to be pretty much in sync (I haven't seen a bias not 1.0000000). However I do use it for video playback as my TV has a 47.952Hz but not a 48.000Hz refresh rate which means not all videos would be well synced without it. If it was broken for whatever reason or didn't work then I could still use the Default DirectShow Output, so the risk associated with the code is low. If however the DirectShow Helper didn't work then MP would give a bad experience therefore the risk associated with the code is high, so Owlsroost's code would need substantially more testing than yours. It wouldn't actually matter to the user if your code was totally broken as it is possible not to use it!

Hope that makes sense to you.

 

[red5goahead]

I'm back. I upgraded my sound card to a Asus Xonar DX.

the multichannel ac3 encoder seem work but now there is a a lot clicks and void in the audio. and the synch loss is come back. even for the 2 ch. test file (top gear) I used in the past.

Attach the log.

 

[tourettes]

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

Also as you can see from this thread the audio renderer receives currently really minimal testing interest. With such it really isn't possible to even think about having the 1.2.0 containing the audio renderer.

I don't see the logic of not having it in 1.2.0 as the the MP Audio Renderer does not have to be chosen, forcing the MP audio renderer into the pipeline would be a different story.

If it was broken for whatever reason or didn't work then I could still use the Default DirectShow Output, so the risk associated with the code is low. If however the DirectShow Helper didn't work then MP would give a bad experience therefore the risk associated with the code is high, so Owlsroost's code would need substantially more testing than yours. It wouldn't actually matter to the user if your code was totally broken as it is possible not to use it!

Even if it would be non-default renderer people would use it (no matter if beta warnings are placed on visible places). It is the same with people using EVR renderer with Windows XP -> creates much work for the support side. So I don't think it is wise to add something that we know is causing already issues (audio renderer is far from ready to replace the MS directsound on "global" scale - for my personal use it works perfectly, there is no single issue spotted during the weeks I have been using it on my HTPC).

After playing with it a lot I now don't use it for TV as my hardware clocks seem to be pretty much in sync (I haven't seen a bias not 1.0000000). However I do use it for video playback as my TV has a 47.952Hz but not a 48.000Hz refresh rate which means not all videos would be well synced without it.

Bias is only the fps vs. frame rate difference. But there is still that v-sync correction that the audio renderer is able to do. If you enable audio renderer and check with ! stats for the "adjustments done". If that is more than zero, then you would benefit from the audio renderer with live tv as well (it will "remove" the dropped frames on the long run that would be caused by slight drifting of the audio / video clocks.) If that value stays at zero then the other audio render is as good choice

 

[tourettes]

I'm back. I upgraded my sound card to a Asus Xonar DX.

the multichannel ac3 encoder seem work but now there is a a lot clicks and void in the audio. and the synch loss is come back. even for the 2 ch. test file (top gear) I used in the past.

Attach the log.

23-08-2010 00:22:59.919 [ 1120] Audio endpoint 0:
23-08-2010 00:22:59.919 [ 1120] Altoparlanti (ASUS Xonar DX Audio Device)
23-08-2010 00:22:59.919 [ 1120] {0.0.0.00000000}.{2343e11e-69de-4461-b781-8cdac6ad6ef1}
23-08-2010 00:22:59.919 [ 1120] supports pull mode: 0

According the driver - event based renderering mode (non-polling) is not supported by the device itself. Shame on the HW maker. Currently the audio device you have is not compatible with the best possible WASAPI mode we have (and MP audio renderer doesn't support anymore the poll based one - the one you earlier had serious trouble with the other audio device(s) ). Of course it could be just the driver that reports the wrong properties to OS / WASAPI, but we cannot know. Maybe you could ask from the manufacturer?

Audio renderer.log itself doesn't show any dropped data, so all buffers that the WASAPI / driver are requesting to be filled are completed nicely.

 

[red5goahead]

According the driver - event based renderering mode (non-polling) is not supported by the device itself. Shame on the HW maker. Currently the audio device you have is not compatible with the best possible WASAPI mode we have (and MP audio renderer doesn't support anymore the poll based one - the one you earlier had serious trouble with the other audio device(s) ). Of course it could be just the driver that reports the wrong properties to OS / WASAPI, but we cannot know. Maybe you could ask from the manufacturer?
Audio renderer.log itself doesn't show any dropped data, so all buffers that the WASAPI / driver are requesting to be filled are completed nicely.

Mhh. Probably Asus Xonar DX/D2/D2X series are most cards on market. Very odd. With silent3 utility can we can get some other information? Anyway there is Asus forum for the question. I'll try but I have to more specific.
note: reclock work in wasapi excl.

silence3 seem work

 

[tourettes]

Mhh. Probably Asus Xonar DX/D2/D2X series are most cards on market. Very odd. With silent3 utility can we can get some other information? Anyway there is Asus forum for the question. I'll try but I have to more specific.

There is other, better MS sample code that can be used to verify the driver behavior a bit better (implementation is done with event based mode - just like with the audio renderer now).

Sample - WASAPI exclusive-mode event-driven playback app, including the HD Audio alignment dance - Matthew van Eerde's web log - Site Home - MSDN Blogs

Could you check how it behaves? If the glitches aren't happening with that, try to find a longer WAV file that has format the WASAPI device accepts (the sample code doesn't do any conversion, so the sample rate, channel amount etc. must match to the device capabilities).

note: reclock work in wasapi excl.

Reclock is most likely using that (ugly) polling based buffer filling since it works with NVIDIA HDMI drivers as well. If it appears that there is huge amount of cards that require the polling option (ugh...) to be used I will consider adding the implementation back as a fail safe registry option (it wont be just copy & paste, but instead requires quite much work to adapt it to coexistent with the event based buffer filling).


As extra test (if you are willing) check:

1) older renderer versions (the ones that have the polling based code still in use)
2) the latest renderer on the different (previously used) audio HW

 

[tourettes]

I'll try but I have to more specific.

I think we need first to figure out if this is only audio renderer issue.

silence3 seem work

But it would show any issues with the buffer handling since it is only playing silent samples.

 

[mironicus]

AW: MediaPortal Audio renderer - better video playback quality

So does only ATI HDMI works flawlessly with the Audio renderer?

Could any other HDMI audio GPU-users report too (Intel...)?

 

[red5goahead]

Mhh. Probably Asus Xonar DX/D2/D2X series are most cards on market. Very odd. With silent3 utility can we can get some other information? Anyway there is Asus forum for the question. I'll try but I have to more specific.

There is other, better MS sample code that can be used to verify the driver behavior a bit better (implementation is done with event based mode - just like with the audio renderer now).

Sample - WASAPI exclusive-mode event-driven playback app, including the HD Audio alignment dance - Matthew van Eerde's web log - Site Home - MSDN Blogs

Could you check how it behaves? If the glitches aren't happening with that, try to find a longer WAV file that has format the WASAPI device accepts (the sample code doesn't do any conversion, so the sample rate, channel amount etc. must match to the device capabilities)

not good.

D:\silence>play-exclusive --device "Altoparlanti (ASUS Xonar DX Audio Device)" -
-file "Iggy pop - Tuff Baby.wav"
Opening .wav file "Iggy pop - Tuff Baby.wav"...
Wave format in file is smaller than a WAVEFORMATEX; will zero-pad the last 2 byt
es.
The default period for this device is 30000 hundred-nanoseconds, or 132 frames.
We ended up with a period of 29932 hns or 132 frames.
^C
D:\silence>

Most of time starts fine but everytime getting worst and became unable to hear after few seconds .

Audio
ID : 0
Formato : PCM
Codec ID : 1
Codec ID/Consiglio : Microsoft
Durata : 4min 27s
BitRate : 1 411,2 Kbps
Canali : 2 canali
SamplingRate : 44,1 KHz
BitDepth/String : 16 bits