AtmoLight - 1.18.6.0 [2016-09-21] (4 Viewers)

[Kotik]

Tried it here again but using older madVR Mediaportal build (1.16pre-release) which remains in sync both with stock settings and when using NGU + SSIM, however do have a new Atmlight build you could try so attached it here.

Unfortunately this build is not working for me at all

The moment I activate the LEDS they remain static with the color that was on screen during the activation, if I switch madvr to full screen exclusive mode then the LEDS do not work at all, not even the initial color is being shown.

 

[Rick164]

Oops used wrong folder for the .mpei file as that was for Mediaportal 1.15 (non-madVR), new version attached

 

[Kotik]

Tried the latest one and it is still lagging

I am out of ideas, even if I completely disable "Filter Mode" in AtmoWin, the LEDS are lagging, in any case without any transition filter I am unable to watch a movie since the results are erratic so i would say with madvr the leds are around 130ms behind.

The moment i activate EVR then everything is back to perfect, i actually have to apply a delay of 30ms in Atmolight to get them in sync.

I did play with different madvr settings but i don't think these had any effect, one idea was to get really low processing times to give time for the renderer to properly handle data to Atmolight, so i used DXVA upscaling for chroma and luma which resulted in 3ms render times (plenty of room for the renderer to do other things) but that didn't help, then i used NGU high which choked the renderer and my results were the same. LEDS are always delayed and the only way to resolve the issue is to use either EVR or capture the image with AtmoWin direcly by bypassing Atmolight.

 

[Rick164]

Could be madVR version related but will see if I can find some more time this week to try out the latest build for it

AtmoLight will push as fast it can from renderer -> OnFrame event which is the same for both EVR and madVR , so expect that somewhere in Mediaportal (madVR part) it's getting delayed but would need to do more testing to confirm.

Btw does it also happen when not using any dynamic refresh rate options (just 50/60hz)?

 

[Rick164]

Tested today with V289 madVR build and LEDs remained in sync with the below settings using Hyperion as I have no way of testing with AtmoWin at the moment, with Hyperion it does offload everything externally (including black border detection) which could have some part to play.
With AtmoWin internal live mode it handles the frames differently (directly of DirectX buffer) and with the AtmoWin API it does have some extra hops but not sure if that could cause it especially since EVR works fine in your case.

Used max settings for all to push the CPU and GPU to the max but remained in sync

 

[Kotik]

I am not sure if madvr settings have any effect on the issue, from my tests the delay remains static no matter the madvr settings, what is really strange is that the same setup will work great with EVR but will have a 130ms delay with madvr, it is too bad that u cannot test it with atmowin, it would be much easier for u to spot the difference directly that way.

I cannot say for sure what is wrong, but if i had to guess i would say that the issue is with the way atmolight is receiving data from madvr, this is the only thing that is changing in my setup, and i can instantly spot the difference.

Like i said previously, with EVR i actually have to use a delay of 30ms to get my leds in sync, in madvr though.... i have to use -130! (this is a minus there).

As u know AtmoWin has transition filters for smooth color change, these filters always add a delay, in my case i got this delay configured to 100ms ( the filter will get activated only during a swift color change, example from a dark scene to a bright one). With EVR even when this filter is being applied my leds are still coming up faster.

U can use the test video file that i uploaded, during the quick color change sequence, EVR is able to keep up in sync always Even when the sequence becomes super crazy With madvr it is just terrible, during the slow changes i already notice that my leds are delayed, but when the sequence speeds up then all hell breaks loose, it is super obvious in the sequence, in rapid change my leds are still showing up the previous color.

I know that during a movie things are more smooth, BUT every scene change my leds are delayed and it is so annoying that i always end up cursing and disabling leds, when they are not in sync they are just distracting.

Not sure that i can add/do something else.

 

[Sebastiii]

I'm not sure it's atmowin related but more madVR code maybe i'm wrong but that's possible. I don't have the hardware to test but for sure directx is taken when RenderOSD code is hit should be when madVR is running but sometimes it can happen some delay freeze (like MP didn't react and RenderOSD is not hit but when running a video it should be ok).

 

[Rick164]

It's odd though that with Hyperion it works, might be able to setup AtmoWin with dummy interface but harder to spot delays (windowed mode is slow atm)
In the Mediaportal madVR code there's no delay of any kind when it triggers AtmolightPlugin_OnNewFrame() right?

Do you have the below "Use GUI data ..." setting on as well?

 

[Sebastiii]

Normally it should not have a delay except if it comes from madVR itself

 

[Kotik]

Do you have the below "Use GUI data ..." setting on as well?

I will check it later today and let u know.