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

[ajp8164]

Hi All,

I've been experiencing a/v drift and thought I'd give the MP Audio Renderer a shot ;-) What I noticed in stats: ~50k frames drawn, ~200 dropped, ~400 adjustments, drift moves nearly continuously (randomly?) between +-7ms (or so). I have ffshow audio codec selected but my graph shows MPC - MPA Decoder (?) How do I make adjustment to have ffshow audio used instead; more to the point - it's what I selected, why is it using MPC?

I've read about the lack of volume support inside MP (and to do with MP not using IBasicAudio etc). Are the necessary changes extensive and intrusive? If this renderer solves my drift issues I'd really (really) like to see volume support inside MP

UPDATE:

Can I use any of these settings to regain MP volume control? I'm not at all familiar with what these will do.

• ForceDirectSound - does this default the use of MPAR altogether?
• WASAPIExclusive - what does setting this to false do?
• WASAPIUseEventMode
• WASAPIPreferredDevice

 

[tourettes]

I've been experiencing a/v drift and thought I'd give the MP Audio Renderer a shot ;-) What I noticed in stats: ~50k frames drawn, ~200 dropped,

~400 adjustments,

Sound quite big number - meaning that A/V clocks are running on quite different rates.

drift moves nearly continuously (randomly?) between +-7ms (or so).

Nothing to worry, just debugging info to see that the internal drift calculation is not jumping out of teh bounds.

I have ffshow audio codec selected but my graph shows MPC - MPA Decoder (?) How do I make adjustment to have ffshow audio used instead; more to the point - it's what I selected, why is it using MPC?

Sounds a bug in MP if wrong decoder gets added to the graph. Or maybe ffdshow doesn't have the specific format enabled and directshow iteself is loading the MPA since it's merits will fit to the reguested format.

Can I use any of these settings to regain MP volume control? I'm not at all familiar with what these will do.

• ForceDirectSound - does this default the use of MPAR altogether?
• WASAPIExclusive - what does setting this to false do?
• WASAPIUseEventMode
• WASAPIPreferredDevice

DirectSound would allow volume control to be used normally - but it is really broken code in there, so I would recommend to stay away from it.

WASAPIExclusive == false -> possibly to control sound volume since OS mixer is handling it when not in exclusive mode. Not recommended since you can only play stereo (or what ever the system might pick up as the default mode - MPAR doesn't have any mixer so it cannot down/up mix the channels).

WASAPIUseEventMode & WASAPIPreferredDevice == not related to the

...so, basicly it is not possible to have volume control currently with MPAR.

 

[Sinbe]

I'm having problems with 2.0 to 5.1 conversion which is disabling (?) time stretching. Here are couple of pictures with refresh rate set to 100Hz. Video is 24fps and the "max bias" is at 1,1 so 24 to 25fps should be working (and is when audio left at default).

100Hz, 24fps video, 2ch

100Hz, 24fps video, upmixing to 5.1

The same thing happens when I set the output channels to anything else than 2.0. Even 1.1 won't work even though the number of channels stays the same. I can also see there's a difference that in one of the pics MP seems to load "default direct sound device" and in the other it doesn't. I used wrong refresh rate in the testing to show the problem more clearly. When using ~96Hz, I get duplicated frames few times a minute and an annoying micro stuttering all the time.

I'm using v0055c version of the dshowhelper with the modified audio renderer found in the other thread, but I had the same problem with the v20 found in this thread.

Edit: It only happens on my Soundblaster X-Fi and not my integrated Realtek so maybe my soundcard can only support WASAPI with 2.0 audio? Is there a way around this somehow?

 

[tourettes]

Edit: It only happens on my Soundblaster X-Fi and not my integrated Realtek so maybe my soundcard can only support WASAPI with 2.0 audio? Is there a way around this somehow?

Please provide the mpaudiorenderer.log - it should show if the audio card fails to support the format (as I would assume it is the cause).

 

[Sinbe]

Logs seem to suggest the soundcard is refusing the format on WASAPI. Yet another bad driver by Creative? Anything I can do about it?

 

[tourettes]

Logs seem to suggest the soundcard is refusing the format on WASAPI. Yet another bad driver by Creative? Anything I can do about it?

Try disabling WASAPIUseEventMode setting in registry. If that wont help I guess there is not much that could be tried.

 

[Sinbe]

Try disabling WASAPIUseEventMode setting in registry. If that wont help I guess there is not much that could be tried.

Tried it already, but it didn't work. I guess it's Creative at fault. Again.

 

[tourettes]

Try disabling WASAPIUseEventMode setting in registry. If that wont help I guess there is not much that could be tried.

Tried it already, but it didn't work. I guess it's Creative at fault. Again.

Is there any SPDIF related modes / settings in the Creative's drivers? It might require such to be turned on so that AC3 can be used.

 

[arion_p]

Could it be the speaker configuration?
I vaguely remember some cards did not support the standard 5.1/7.1 speaker arrangement and we had to patch the speaker mask.

 

[tourettes]

Right now are there any kind of registry entries I could use to experiment with?

Currently only way to poke those quality related settings is to modify the code. When I next have some extra, extra free time I'll expose following set of registry keys:

      // settings from Reclock - watch CPU usage when enabling these!
      /*bool usequickseek = false;
      bool useaafilter = false; //seems clearer without it
      int aafiltertaps = 56; //Def=32 doesnt matter coz its not used
      int seqms = 120; //reclock original is 82
      int seekwinms = 28; //reclock original is 28
      int overlapms = seekwinms; //reduces cutting sound if this is large
      int seqmslfe = 180; //larger value seems to preserve low frequencies better
      int seekwinmslfe = 42; //as percentage of seqms
      int overlapmslfe = seekwinmslfe; //reduces cutting sound if this is large

      m_pSoundTouch->setSetting(SETTING_USE_QUICKSEEK, usequickseek);
      m_pSoundTouch->setSetting(SETTING_USE_AA_FILTER, useaafilter);
      m_pSoundTouch->setSetting(SETTING_AA_FILTER_LENGTH, aafiltertaps);
      m_pSoundTouch->setSetting(SETTING_SEQUENCE_MS, seqms); 
      m_pSoundTouch->setSetting(SETTING_SEEKWINDOW_MS, seekwinms);
      m_pSoundTouch->setSetting(SETTING_OVERLAP_MS, overlapms);

...currently I'm busy with some non-audio renderer related stuff that eats all my free time.

Here's a quick test binary for the quality control. All six settings from SoundTouch library has been exposed. Default values will be written to registry on the 1st run. There is no other changes in the renderer itself.

Straight from the SoundTouch source code:

/// Enable/disable anti-alias filter in pitch transposer (0 = disable)
#define SETTING_USE_AA_FILTER       0

/// Pitch transposer anti-alias filter length (8 .. 128 taps, default = 32)
#define SETTING_AA_FILTER_LENGTH    1

/// Enable/disable quick seeking algorithm in tempo changer routine
/// (enabling quick seeking lowers CPU utilization but causes a minor sound
///  quality compromising)
#define SETTING_USE_QUICKSEEK       2

/// Time-stretch algorithm single processing sequence length in milliseconds. This determines 
/// to how long sequences the original sound is chopped in the time-stretch algorithm. 
/// See "STTypes.h" or README for more information.
#define SETTING_SEQUENCE_MS         3

/// Time-stretch algorithm seeking window length in milliseconds for algorithm that finds the 
/// best possible overlapping location. This determines from how wide window the algorithm 
/// may look for an optimal joining location when mixing the sound sequences back together. 
/// See "STTypes.h" or README for more information.
#define SETTING_SEEKWINDOW_MS       4

/// Time-stretch algorithm overlap length in milliseconds. When the chopped sound sequences 
/// are mixed back together, to form a continuous sound stream, this parameter defines over 
/// how long period the two consecutive sequences are let to overlap each other. 
/// See "STTypes.h" or README for more information.
#define SETTING_OVERLAP_MS          5