Any working Version for Mac OS ?

[amrap030]

Hello together,

I just set up a WS2812b led Strip wit 17 leds on top and bottom and 10 leds on the sides which equals to 54 leds in total. Then I wanted to controll an arduino uno with adalight and fast led with the latest Prismatik build Version 5.11.2.22. I also tried other builds but with no luck. The light is very laggy, sometimes shows wrong colors and Prismatik seem to slows down my computer in screen grabbing mode. I am using a Macbook Pro 15" with macOS Mojave 10.14. When I playback a youtube video or do something else on my PC the framerate drastically decreases and the video doesn't playback in real time anymore. Also when I move my cursor around in the browser the light is flickering sometimes. When I playback a mood lamp, for example the color rainbow, it playbacks perfectly fine and looks very good and nicely faded.

These are my settings:

I hope you can help me :)

[zomfg]

What resolution?

Try this tool with

• 0.2, 0.05, 0.03 scale (press enter each time, the picture should get noticeable pixelated)
• 40 fps or whatever you have in Prismatik
• check cpu/gpu usage, post screenshots

Also try this older test build

[amrap030]

@zomfg

I have an external monitor on my Macbook Pro which has a resolution of 3840 x 2160. Here is what I observed:

I set the AVScreenShack to 0,2 with maximum 40FPS and the CPU usage was around 13,7 % with Youtube Video Playback

At 0,05 the CPU usage was around 11,8 % with Youtube Video Playback

At 0,03 the CPU usage was around 9,5 % with Youtube Video Playback

The GPU usage showed the following result (from left to right):

1. AVScreenShack @0,2 with Youtube Video Playback
2. AVScreenShack @0,05 with Youtube Video Playback
3. AVScreenShack @0,03 with Youtube Video Playback

After this I did a Test with Prismatik:

With Video Playback I got a CPU usage at about 19,4 % with Prismatik

Without Video Playback I got around 10,1 % of CPU usage with Prismatik

The GPU usage showed the following result (from left to right):

1. Youtube Video playback with Prismatik Screen Grabbing
2. No Youtube Video Playback at all but Prismatik Screen Grabbing open
3. Youtube Video Playback without Prismatik or AVScreenShack open

For the tests with Prismatik I used the build you provided.

[zomfg]

nice, thanks! so does that build have the same issues? do you have performance issues when running the AV tool?

[amrap030]

@zomfg I tested it again and I actually think this build indeed performs a lot better than all the others I tested. The Video Playback is almost realtime (with Prismatik or AVScreenShack no difference), sometimes there is a very short framedrop I think. But I always have the feeling that the light is still a bit laggy and the color changing is not really smooth, especially when I scroll on websites. Compared to my ambilight on my TV, which works with hyperion, this ambilight is not 100% as I expect.

In addition I noticed a lot of wrong colors when playing an ambilight test video on youtube:

https://streamable.com/uh43lk

It feels like the light needs some time to function properly because at a certain time it worked okay. I don't know what to do anymore, maybe this is a performance issue due to the low framerate and the high GPU usage. Hopefully this can be fixed somehow?

[zomfg]

So this video is of the test build?

Do you have multiple GPUs? What's your baudrate? Do you have the same baudrate on your arduino? If you display colored grab widgets (your very first screenshot) do all LEDs look fine? (with normal and test build)

[amrap030]

yes this video is of the test build. I don't have multiple GPUs and I have a baudrate of 115200 on both. The colored grab widget is not really accurate reproduced from the leds.

[zomfg]

Could you show how it looks with both (if different results) builds? While you do it could you set your logs to 2 and attach here and could you show AV tool at 0.03 scale

[amrap030]

where can I find the log file?

[zomfg]

~/.Prismatik/Logs

[amrap030]

These are the two log files:

1. Test Build:

Prismatik.0.log

2. latest build:

Prismatik.0.log

This is the AV Tool set to 0.03 scale:

This is how it looks on both builds:

[zomfg]

run mkdir -p /tmp/priz in your terminal run this build, it'll save frames in that tmp folder so run pretty much same kind of tests, post frames zip and logs (avoid showing personal stuff, and watch out for free space in tmp, maybe lower framerate)

also uncheck "apply screen color modif" to eliminate another variable

[amrap030]

I did a test with all the settings you mentioned above. These are the frames but for some reason it gave me no log files with logging level set to 2. Should I also do performance tests or was this test just for color reproduction? At first sight on the frames I noticed some kind of aspect ratio problem and the lower 3/4th of the picture is just stretched to the bottom. This explains that the grab widget does not show a lot of diversity in colors.

priz.zip

[amrap030]

Also I feel like unchecking the option "apply screen color modif" fixed the jumping colors at the start of the video you have seen from my screen. It may be luck but I have not experienced those color jumps so far :)

[zomfg]

Did you delete the logs manually with Prismatik running? That could be the cause. Quit Prsimatik, delete Logs folder and relaunch should fix that.

Interesting... the weird aspect ratio thing is a known issue (something on the macOS/driver/sdk side), that I thought was occurring on 10.13 and below. On 10.14.2 and up I wasn't able to reproduce, so I made Prismatik detect the os version and apply the scaling accordingly. Which 10.14 are you on precisely?

What happens is when you go under 0.17 (in 1:1 resolution and half that in retina, depending on your display scaling) the image is squeezed vertically more and more the lower you go and the bottom row of pixels is stretched. You can play around with the AV tool to see that.

So unfortunately it looks like it'll be safer with the larger scale no matter the version. Which comes with a small performance hit. So here's another build to run your test on.

Performance wise just check if it's too unusual, but as I said expect it to be slightly higher.

While we are at it, could you do two sets of tests (so 2 logs and 2 frame folders): one with and one without "apply screen color modif"

[amrap030]

Here are my tests with the build you provided in your last post:

These are my results without the option "apply screen color modif":

without_modif.log Frames: https://easyupload.io/4k5295

These are my results with the option "apply screen color modif": with_modif.log Frames: https://easyupload.io/a21z1r

This option definitely causes the jumping colors you could see in my video. When I checked this option and saw the YouTube video you can see in the frames I had jumping colors again, but they don't seem to appear in the frames. When unchecking this option these jumping colors never occurred.

Now I think the only problem is the performance. Video playback is almost there but the synchronization of the colors to the video is still laggy and half a second behind the video. Fading colors does not feel like decrementing from 100 to 99, 98, 97, 96... It feels more like big steps like from 100 to 90,80,70 ... (I don't know how to describe it).

[amrap030]

But I have to admit, this build is by far the best one it goes in the right direction :)

[zomfg]

Try to capture the jumping colors with this build with motif checked. It should work the same as previous build. Just the log file should be enough this time.

Do you have Night Shift enabled? Test the opposite for jumping colors.

Maybe a video of your lag issue? (without jumping colors)

[amrap030]

Here is the log with the previous build and modif checked.

Prismatik.0.log

I don't use night shift. I am actually pretty happy with this build but the lag issue is hard to capture on camera. I always have the feeling that when the picture on the screen changes the lights need like half a second to adapt to the new picture. Maybe this is normal I don't know. I also think if I would get a bit more framerate I think the result would be better but other than this build works pretty good.

[zomfg]

Could you also post your profile (same place as Logs) that you use for grabbing And could you run the same test (modif checked and logs) with "Scene luminosity threshold" at 0 please

is it really half a second (pretty long) or more like few frames? While I believe 115200 baud should be enough for your setup, try doubling it just to see

[ndfred]

Stumbled across this as well, and seeing the effect being delayed ~0.5s / 1s as well, although this is with WLED over UDP. When I use music mode, it reacts instantly. I do use a 5K external display with my MacBook Pro so wouldn't be surprised if processing gigantic screenshots takes a bit of time. I use Mac AV as well, and my CPU is around 25% booked by Prismatik. Happy to send logs or run tests if that can help improve latency. And thanks for putting so much effort into this! Using AVScreenShack reducing the scale makes a big difference: scale of 1 pegs the core to 100% when 0.1 scale gets that down to 10% and looks very reasonable to average the colour for each LED.

[ndfred]

I just tested it with Adalight instead of UDP and it is much more responsive. The CPU utilisation issue I am seeing might be close to this one: https://github.com/psieg/Lightpack/issues/262 I will try the suggested version there and see if that improves anything: https://github.com/zomfg/Lightpack/releases/download/5.11.2.18-grab-alpha/Prismatik-safe-scale.dmg Update: I don't see any difference in CPU consumption, still really high.

[zomfg]

that build has the same scale as the last release, so that's expected

• what framerate?
• which UDP protocol? is it the same with the other two?
• what CPU usage with AVScreenShack at 0.2?

and do show the logs, yes

[ndfred]

A bit more context about my setup:

• I don't have a dedicated GPU, maybe that is a factor: MacBook Pro (13-inch, 2019), 2.8 GHz Quad-Core Intel Core i7, Intel Iris Plus Graphics 655 1536 MB
• LG UltraFine 5K over Thunderbolt as an external monitor (no other monitor attached)

Just tested again:

• with Prismatik: 40/50 FPS, 30~40 FPS
• UDP protocol to WLED, DRGB protocol

AVScreenShack at 60 FPS:

• Scale 1: 100%
• Scale 0.5: 37%
• Scale 0.2: 15%
• Scale 0.1: 12%

I looked through the logs but didn't see anything really compelling, though I was in log mode 1. What would you suggest I look for / share?

[zomfg]

the CPU usage does not look shocking to me how many LEDs? did you try the WARLS/DNRGB protocols? is it more responsive with a lower framerate?

[ndfred]

I have 30 LEDs, this is just a test strip at the top of the screen before I go for the full setup. How much CPU usage would you consider acceptable? In order to leave this on all the time, I would have expected < 5%.

Since the scale makes a large difference, what is the current scale value and can it be customised? Does it change with pixel density? I would imagine you one would need a pretty low resolution capture to extract average colours. I also wonder if it is possible and potentially faster to just extract bands rather than capture the full screen.

Protocol-wise I've tested DRGB and Adalight, I don't remember DNRGB and WARLS working (I use WLED). I have not tried responsiveness at a lower framerate. I would rather focus on the CPU load first though.

And thanks for your help!

[AlexKusnezov]

@zomfg @ndfred I have 2x 4k displays which render at 3008x1692 with 372 LED in total around it, which results in 50-70% GPU load all the time. Is there a way to reduce the grabbing quality to free up some gpu?

my config:

[Adalight]
BaudRate=921600
ColorSequence=RGB
LedMilliAmps=50
NumberOfLeds=372
PowerSupplyAmps=0
SerialPort=/dev/cu.usbmodem14301

Also when I run prismatik the process WindowServer has a higher GPU load:

Prismatik running (WindowsServer 17.8%):

Prismatik NOT running (WindowsServer 2%):

[zomfg]

in your case the captured image is already around 600x340 so going lower won't be a dramatic change here and there is (was?) a bug somewhere with macos capture (in general) where the image would get corrupted (squished) after a certain threshold, so the current scale is just above that point (@20%) you can play with this to try different scales

[AlexKusnezov]

@zomfg thanks for the tool: Unfortunately I can capture only one screen with AVScreenShack_10.15 so with this settings the load of the gpu from the app is 8.5%:

so should be 30% percent highest from Prismatik right? Do you know where and how I can adjust the scaling for Prismatik app?

[zomfg]

this tool is very small and does nothing other than showing the images so not a lot of overhead compared to prismatik, so the gap isn't too wild you could backup ~/.Prismatik and redo quick and dirty single display config in prismatik for a closer comparison the scale value is hardcoded in prismatik https://github.com/psieg/Lightpack/blob/9e0d7edd00f29b938c55fbccd78a51892d1b714c/Software/grab/MacOSAVGrabber.mm#L21

did you try 0.1, 0.05 in the tool?

[AlexKusnezov]

@zomfg

did you try 0.1, 0.05 in the tool?

yes, unfortunately everything under 0.2 is messed up at the bottom

I'm just looking for ways to reduce gpu load, since the fans ramp up every time