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

[tourettes]

Ah, that assumes I have an amp. I just have computer speakers, so the only way I can control the volume is through the PC.

Assumptions are sometimes having some bad side effects

to be able to implement the volume control, I would need two things:

1) some DS interface to the audio renderer so it sees the volume change requests (IBasicAudio maybe?)
2) some GPL code that can do high quality volume control (preferably for multichannel stream, also required to work with integer and float samples)

Maybe someone could try to google a bit for those? It would save my time.

 

[arion_p]

Applying the volume control isn't that hard to get high quality results. Doing a float multiplication or a muldiv (for integer samples) combined with some noise function (already implemented for down-sampling bit depth, but perhaps not high quality - we could use a good GPL noise function if we could find one) should produce adequately high quality results.

It is integrating the volume control in a standard way that I know nothing about.

 

[tourettes]

Applying the volume control isn't that hard to get high quality results. Doing a float multiplication or a muldiv (for integer samples) combined with some noise function (already implemented for down-sampling bit depth, but perhaps not high quality - we could use a good GPL noise function if we could find one) should produce adequately high quality results.

Sounds like a task for you btw this would be again one "plugin" in the processing chain, so we would definitely need to refactor the code to allow us to expand the possible audio processors easialy.

It is integrating the volume control in a standard way that I know nothing about.

I'll Google a bit and do some experimenting.

 

[davidf]

Audio Renderer is in the graph and working for shared mode with Nvidia GPU - although the audio always drops for about 5 seconds about 10 seconds after starting the channel (HD channel). I've also had my first MediaPortal lockup in ages when changing from HD with AC3 to SD with MPEG Audio. The Audio totally failed after that and I've disabled the Renderer and sound is back on the HD and SD channels.

Apologies for the brevity, I'll get some more testing done when I can.

I can answer the last one myself - I didn't fix the device and so it has picked the speaker socket on the computer. This would definately provide no sound on the TV

 

[tourettes]

Audio Renderer is in the graph and working for shared mode with Nvidia GPU - although the audio always drops for about 5 seconds about 10 seconds after starting the channel (HD channel).

d3dapp: Graphic adapter 'NVIDIA ION' is using driver version '8.17.12.5896'

ION doesn't have enough CPU / GPU power to combine audio renderer (timestreching requires quite much CPU and ION has less than minimal CPU reserve).

Audio renderer needs to drop lot of samples based on the log. Same has been seen on team's internal testing. Looks like ION's wont be able to take use of the new audio renderer (unless we manage to optimize the code more).

I've also had my first MediaPortal lockup in ages when changing from HD with AC3 to SD with MPEG Audio. The Audio totally failed after that and I've disabled the Renderer and sound is back on the HD and SD channels.

Looks like MP itself would have had quite serious error:

2010-08-17 21:33:46.859200 [Info.][MPMain(1)]: Exception   :System.NullReferenceException: Object reference not set to an instance of an object.
   at MediaPortal.Player.BaseTSReaderPlayer.Process()
   at MediaPortal.Player.g_Player.Process()
   at MediaPortalApp.OnProcess()
   at MediaPortal.D3DApp.Application_Idle(Object sender, EventArgs e)
   at System.Windows.Forms.Application.ThreadContext.System.Windows.Forms.UnsafeNativeMethods.IMsoComponent.FDoIdle(Int32 grfidlef)
   at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
   at System.Windows.Forms.Application.Run(Form mainForm)
   at MediaPortalApp.Main(String[] args)

This would probably stop the rendering loop completely and seems as a hang to user.

 

[davidf]

d3dapp: Graphic adapter 'NVIDIA ION' is using driver version '8.17.12.5896'

ION doesn't have enough CPU / GPU power to combine audio renderer (timestreching requires quite much CPU and ION has less than minimal CPU reserve).

Audio renderer needs to drop lot of samples based on the log. Same has been seen on team's internal testing. Looks like ION's wont be able to take use of the new audio renderer (unless we manage to optimize the code more).

Actually the results were much better after a reboot. The renderer still dropped multiple samples at the start but then was fine. Just realised - the start is where the audio stream is being stretched therefore the AudioRenderer is working, when the audio stream is not being stretched then the audio would be passed through and therefore the processing requirements would drop. Would this be a correct assumption? I've only seen the dropping on interlaced HDTV which would be put the maximum strain on the rest of the system. SD and progressive High definition were fine.

 

[tourettes]

Actually the results were much better after a reboot. The renderer still dropped multiple samples at the start but then was fine.

Maybe there was some background process using CPU cycles in the 1st time? We newer know

Just realised - the start is where the audio stream is being stretched therefore the AudioRenderer is working, when the audio stream is not being stretched then the audio would be passed through and therefore the processing requirements would drop. Would this be a correct assumption? I've only seen the dropping on interlaced HDTV which would be put the maximum strain on the rest of the system. SD and progressive High definition were fine.

If you are using 1:1 or 1:2 matching video, then the bias shouldn't ever be anything else than 1.0. But I know that the Microsoft's DTV-DVD video decoder in Windows 7 is at least altering the video frame rate(!) when it hits a performance issue and that triggers the bias to change to non 1.0. For example 25fps video could be set to 23.976 or something else as ugly. In normal cases this wont matter, but with this specific audio renderer it will since it is dependant on the EVR presenter's information.

One check would be to test some other HW H.264 decoder.

About the strecthing and CPU usage... yes, it should require more CPU when the strecthing is happening. Not sure if the requirement is different when the bias is 1.0 and only minor changes are done or when the bias is around 1.004 (23.976 to 25).

 

[robyf]

One check would be to test some other HW H.264 decoder.

I can confirm powerdvd9 H.264 codec works much better than microsoft with ION here, with no drops at beginning of the video.

 

[davidf]

Can I raise a tiny bug too. Your log file date format is different from the rest of Mediaportal, your logs have date in the format DD-MM-YYYY HH:MM: SS:FFF mediaportal uses YYYY-MM-DD HH:MM: SS:FFFFFF, also your logfile has empty lines in it which is different to mediaportal too. I've knocked up something to combine multiple logfiles to get a single timeline and your logfile didn't parse first time (Really I just like consistency ).

The dropping mostly happens when the bias is set to 1.040956 (the detected framerate is 50, but had been incorrectly 47.952 when the bias was selected and it also detected 59.94 at one point). It then trys at a framerate of50 with a bias of 1 and playback with audo is correct within 0.5 seconds.

 

[tourettes]

Can I raise a tiny bug too. Your log file date format is different from the rest of Mediaportal, your logs have date in the format DD-MM-YYYY HH:MM: SS:FFF mediaportal uses YYYY-MM-DD HH:MM: SS:FFFFFF, also your logfile has empty lines in it which is different to mediaportal too. I've knocked up something to combine multiple logfiles to get a single timeline and your logfile didn't parse first time (Really I just like consistency ).

EVR presenter is using the same logging "format" as audio renderer (minus the few empty lines, which were added to make it more readable for few places). I think it is better to be in sync with the EVR presenter since audio renderer is more likely to need the log comparisions against that than the MP (althout it is needed as well).

The dropping mostly happens when the bias is set to 1.040956 (the detected framerate is 50, but had been incorrectly 47.952 when the bias was selected and it also detected 59.94 at one point). It then trys at a framerate of50 with a bias of 1 and playback with audo is correct within 0.5 seconds.

Any change that you are using Microsoft DTV-DVD video decoder? Since it will be reporting wrong framerates when it has issues with the performance (GPU / CPU). Unfortunately the EVR presenter sees only the information the codec / EVR mixer is sending to it, at least I know no way to detect the real framerate without codec being able to give "false" information. Why MS decoder does such? I guess it tries to lower the rendering speed to give less stuttering playback results.