MediaPortal Audio Renderer (1 Viewer)

[tourettes]

edterbak, I see two different issues in the logs you have posted.

1) Same issues as red5goahead is having with the Xonar 5.1 (and probably 7.1 as well) - I'll try to find some free time to build a debug version that would have more logging about those format negotiations so we could hopefully see why it will fail. I'll also try to override some of those channel masks that DS provides and trigger the issue on my dev PC with Nvidia GPU / HDMI.

2) Dropped samples on both Xonar and AMD HDMI. This could be either but in MPAR (more likely) or some issue with the system / drivers. Please try to increase the DevicePeriod to 500000 or even more to see if helps or makes the sample dropping to happen with a different intervals. Now it looks like the sample dropping is happening with around 3 minute interval.

21-05-2012 21:48:36.584 [ 840] sample start: 226.200 stop: 226.428 dur: 0.228 diff: 0.000 rtHWTime: 226.211 rtRefClock: 226.168 early: -0.010 queue: 18 4.323
21-05-2012 21:48:36.584 [ 840] dropping late sample - pDueTime: 226.200 rtHWTime: 226.211
21-05-2012 21:48:36.584 [ 840] sample start: 226.428 stop: 226.655 dur: 0.228 diff: 0.000 rtHWTime: 226.211 rtRefClock: 226.168 early: 0.217 queue: 17 4.096
21-05-2012 21:48:36.584 [ 840] MPAR_S_WAIT_RENDER_TIME - 226.428
21-05-2012 21:48:36.584 [ 840] calculateSilence: 0.217 pDueTime: 226.428 rtHWTime: 226.211
21-05-2012 21:48:37.024 [ 840] sample start: 226.655 stop: 226.883 dur: 0.228 diff: 0.000 rtHWTime: 226.651 rtRefClock: 226.608 early: 0.005 queue: 18 4.323

21-05-2012 22:09:09.825 [ 1c0] sample start: 410.299 stop: 410.469 dur: 0.171 diff: 0.000 rtHWTime: 410.309 rtRefClock: 410.277 early: -0.010 queue: 18 3.243
21-05-2012 22:09:09.825 [ 1c0] dropping late sample - pDueTime: 410.299 rtHWTime: 410.309
21-05-2012 22:09:09.825 [ 1c0] sample start: 410.469 stop: 410.640 dur: 0.171 diff: 0.000 rtHWTime: 410.309 rtRefClock: 410.277 early: 0.160 queue: 17 3.072
21-05-2012 22:09:09.826 [ 1c0] MPAR_S_WAIT_RENDER_TIME - 410.469
21-05-2012 22:09:09.826 [ 1c0] calculateSilence: 0.160 pDueTime: 410.469 rtHWTime: 410.309
21-05-2012 22:09:10.155 [ 1c0] sample start: 410.640 stop: 410.811 dur: 0.171 diff: 0.000 rtHWTime: 410.639 rtRefClock: 410.607 ea

Note that I do however have the 1551 channel mask still active in the registry.

Even if is it present in the registry it wont be used - you can safely delete it from registry.

 

[tourettes]

With 500000 value I've not any problem . I watched two episodes with no issues.
The eventmode was on.

Thanks for reporting. 10 ms is quite short amount of time and it could be possible that some other process (or MP itself) is not allowing the MPAR scheduling to happen so often.

Don't forget the option Auto for speaker... based on operating system audio driver settings when avaiable or based on source channels when not (for example with the Realtek digital output )

Based on system setting would make probably some sence (but I would need to find some free time to implement such ).

Based on audio format doesn't make any sence since it already works like that automatically if you wont apply the Force up/down mixing setting. MPAR will render the stream as it is if the output device accepts the format (when no force up/down mixing is selected) and if the output device rejects the format the MPAR will try downmixing the channel layout to the user configired value (which should work unless user has made an error - MPAR will test all possible sample rate, bit depth conbinations as well - unless user has forced some specific values to be used).

So if there is 4.0 stream and speker config is set to 5.1 the output will be 4.0 (unless Force up/down mixing is enabled - in that case the output would be upmixed 5.1).

 

[red5goahead]

So if there is 4.0 stream and speker config is set to 5.1 the output will be 4.0 (unless Force up/down mixing is enabled - in that case the output would be upmixed 5.1).

Ah ok. now It's clear at all.

My suggest: when force up/down mixing is disabled let's make as not enabled the speaker setup combobox with an "auto" text label inside,
when Force up/down mixing is enabled re-enable that control (without auto option).
Though I suppose that option panel will be included into standard MP setup.

 

[tourettes]

My suggest: when force up/down mixing is disabled let's make as not enabled the speaker setup combobox with an "auto" text label inside,

As MPAR doesn't currently know what speker config the system has it has to have the option to configure the wanted output mode (even for the auto behavior).

Though I suppose that option panel will be included into standard MP setup.

1.3.0 will allow all (selected) directshow filters to be configured directly from the config.

 

[edterbak]

Hi tourettes,

I will test some more. I have the feeling after trying with the default audio renderer the same issue is there. I need to confirm this with a propper test though.
Later this evening I probably have time to test.

But, If needed, an other Xonar tester available here

 

[micko]

Hi, now our old plasma finally terminated it work agreement and I am back using this with my new setup (yes now with the new tv it's possible to set dynamic refreshrate too). Skipped many versions, but latest MPAR v2 with tsreader v53a is working such perfect for me. Moving picture (specially panning) is looking nice and smooth. Setting dynamic refresh rate didn't do it alone. I do some more testing with different formats and report then more. Only first have to solve some problem with my audio driver losting always my 7.1 amp and seeing only stereo TV behind it (some hdmi/hdcp problem). Still keep up the great work dude

 

[red5goahead]

With 500000 value I've not any problem . I watched two episodes with no issues.
The eventmode was on.

Thanks for reporting. 10 ms is quite short amount of time and it could be possible that some other process (or MP itself) is not allowing the MPAR scheduling to happen so often.

Mhh. I got some problem with the sound for few second (two - three times) . But the AudioRenderer.log do not display any issues . (Since few days ago I start MP in debug mode all the times)
at 20:10, 40:10 mm:ss ...

 

[edterbak]

edterbak, I see two different issues in the logs you have posted.

1) Same issues as red5goahead is having with the Xonar 5.1 (and probably 7.1 as well) - I'll try to find some free time to build a debug version that would have more logging about those format negotiations so we could hopefully see why it will fail. I'll also try to override some of those channel masks that DS provides and trigger the issue on my dev PC with Nvidia GPU / HDMI.

2) Dropped samples on both Xonar and AMD HDMI. This could be either but in MPAR (more likely) or some issue with the system / drivers. Please try to increase the DevicePeriod to 500000 or even more to see if helps or makes the sample dropping to happen with a different intervals. Now it looks like the sample dropping is happening with around 3 minute interval.

Hi Tourettes,

I did some more testing. All previous logs are produced using 6ch PCM 48kHz output through SPDIF. I can also use Dolby Digital Live as output. This encodes any audio stream to dolby digital on the fly.

I installed the latest official ASUS Xonar drivers. They are buggy ofcourse, but official. Maybe there is an effect...
I set DevicePeriod = 500000
Eventmode = 1 in all logs.

Xonar output variation:
Xonar PCM 48kHz 6ch output + Device Period = 500000
I did not experience the audio cut outs anymore, but the dropped frames were still there occasionally. See logs an screendump.


Xonar "Dolby Digital Live" + Device Period = 500000
I did not experience the audio cutoffs anymore. But there were still the occasional drops of frames. See logs.


Xonar Dolby Digital Live + 500000 Device Perdiod - Not using MPAR log
I fell asleep during this test. No observations But I ...think.. the dropped frame counter said 37 directly after starting the file....

 

[gibman]

tried tsreader + MP AR combo from 1.3.0 alpha branch.

No crashes so far during channel changes.

Channel changes across cards as well as on the same card is def. slower.. feels like twice as slow as before.
Also a few channel changes resulted in no audio. About 3-4 sec later and the audio begins.

reclock for TV does not seem to have either of those 2 issues.

/gibman

 

[tourettes]

edterbak and/or red5goahead:

Please test the attached .ax with the Xonar and 5.1 (and 7.1 if possible) samples. The alternate channel mask testing is done in a different way. Hopefully it works, as it works on faked incoming data at least (1551 gets converted to 63 which is the opposite that Xonar will require...).