UDP Sync with WLED

[qu4nt4r]

I am kind of attached to the WLED community and tried to connect your CC app to WLED (i.e. the esp32 running it). Via UDP Sync it "kind of worked", but all LEDs either only got one color or showed strange patterns. With my limited knowledge and skills in coding I presume that CC doesnt match the UDP pattern of WLED???
Furthermore I couldnt add/change LEDPatterns/ledpatterns and more within the config file to match the WS2812B order ("[WRN] Unknown config entry found: "paddingcontent". Ignoring.")
Maybe you could help me/us out linking both, especially as there were just the release of the sound reactive branch. Would be really cool to have another sound reactive input option to play with. :)

Greetings
Kelvin

[CaiB]

Hello, thanks for stopping by!

First time I'm hearing of that project, and by taking a glance at the linked UDP packet structure, it does require the first 2 bytes to have special data. Since we'd want to use their DRGB mode, we need byte 0 to be 2. Since ColorChord.NET will fill all padding bytes with the same data, that means as of right now you're forced to use 2 seconds as the timeout value as well (byte 1). If that's fine, set your PacketUDP config section to have these (in addition to the address, port, etc):

"PaddingFront": 2,
"PaddingContent": 2,
"LEDPattern": "RGB"

This tells it to have 2 bytes of padding at the front, both filled with the value 2, then all of the data in [RGB][RGB][RGB]... format

Note the config parameter names are case-sensitive (which is why you get that warning, since you had "paddingcontent" instead of "PaddingContent".

Could I have you try that out and let me know if it works?

[qu4nt4r]

Thanks! Though I still got a "[WRN] Unknown config entry found: ... with all three config entries while using the release build, it worked fine using the actual auto-build (config seems similar). I will play around with the config possibilities to get a bit more familiar with the options. Any other advice regarding the performance/for optimization?

[CaiB]

Ah yes, sorry about that. I forgot to mention the release version is a bit behind at the moment for config options.

Regarding performance, the biggest tip is to just remove things you aren't using. The default config has a DisplayOpenGL window shown on the desktop. If you don't want to see it, just delete that whole entry from the Outputs section. If you're just using 1 visualizer with a PacketUDP output, I've seen extremely good performance. Just for testing I was able to push 300+ FPS with 100s of LEDs per packet, without too significant CPU stress. I can push 100+ Mbps just in UDP LED data without maxing out a core.

For my daily usage, I'm outputting 50 LEDs at 90 FPS over UDP only, and even on the several year-old laptop I use in my media center, CPU usage is under 1%. I built a custom Ethernet-connected RPi receiver that has no trouble outputting this.

In short, just turn off unused things, and performance shouldn't even be a concern on the PC side. I'd be much more worried about the ESP32/receiver being able to keep up.

[qu4nt4r]

Thank you for sharing your experience, I´ll dig into it. Keep on doing what you´re doing :)

[qu4nt4r]

Hi there its me again :)
I took a look at your port again and in general it works fine with my WLED based lighting fixtures. But as I added the second one, a 1024 LED matrix, it just didnt react to the UDP streaming while my first one worked without any issues with the same basic config. After trying out a lot of random stuff, I found out that there is a limit regarding the LED amount. It is exactly 490, 491 doesnt work. The number doesnt make any sense to me. The matrix works fine with any other UDP based audio-reactive software, but I atm have no clue why not here. I will investigate it further as good as I can, but maybe you have an idea regarding the cause and/or for a workaround/solution.
Greetings and thanks :)

EDIT: Ok found it. Its the max cap of the DRGB protocol. Will take a look at the WLED side if there is a solution to this one.

Here is the config

"Visualizers":
[
    {
        "Type": "Linear",
        "Name": "SampleLinear",
        "LEDCount": 284,
        "IsCircular": true,
        "FrameRate": 60,
        "LightSiding": 1.0,
        "SteadyBright": false,
        "LEDFloor": 0.1,
        "LEDLimit": 1.0,
        "SaturationAmplifier": 1.6,
        "Enable": true
    
        "Type": "Linear",
        "Name": "1024wall",
        "LEDCount": 490,
        "IsCircular": false,
        "FrameRate": 60,
        "LightSiding": 1.0,
        "SteadyBright": false,
        "LEDFloor": 0.1,
        "LEDLimit": 1.0,
        "SaturationAmplifier": 1.6,
        "Enable": true
    }
],
"Outputs":
[
    {
        "Type": "PacketUDP",
        "Name": "SampleUDP",
        "VisualizerName": "SampleLinear",
        "IP": "192.168.1.179",
        "Port": 21324,
        "PaddingFront": 2,
        "PaddingContent": 2,
        "PaddingBack": 0,
        "LEDPattern": "GRB",
        "Enable": true
    
        "Type": "PacketUDP",
        "Name": "1024",
        "VisualizerName": "1024wall",
        "IP": "192.168.1.16",
        "Port": 21324,
        "PaddingFront": 2,
        "PaddingContent": 2,
        "PaddingBack": 0,
        "LEDPattern": "GRB",
        "Enable": true
    },

[qu4nt4r]

Sadly there is no easy solution for this from WLED side as Aircookie (the main dev) mentioned. If you may find a workaround for this problem from the CC side to get this running this would be really cool.. I then at least could offer to write a short paragraph at the UDP-part within the WLED wiki to mention your CCnet work. I am pretty sure that there may be others within the WLED community that may like to use the software.
greetings
Kelvin

That software seems cool! Unfortunately there is no way of raising the UDP packet size with the current network stack, so 490 LEDs are the ceiling for any given packet 😦 WLED supports several protocols that split the frame into multiple sequenced UDP packets (E1.31, Art-Net, DDP and TPM2.net, with DDP and TMP2.net being the easiest to implement with the least overhead since they don't aim to be DMX compatible with all the universe stuff). If the ColorChord developer would consider adding one of these standards, driving a 1024 LED matrix should work fine (I believe one guy even got a 2k matrix working once) :slight_smile:

[CaiB]

Hi again!

I guess that's not too surprising. 490 LEDs x 3 colours = 1470 bytes, add the headers and other stuff and that's right in the neighbourhood of typical network MTUs, the maximum size for single transmissions. Any packet larger than this gets fragmented (split into multiple parts), and I'm guessing the network stack in WLED doesn't support UDP fragmenting or jumbo frames. Fair enough.

I'm a bit busy right now, so it'll probably take me a few days to get around to this, but implementing one of those protocols doesn't sound too bad. (I found this documentation on TPM2.net). I also really should port some of the 2D LED matrix visualizers over, as right now CC.NET doesn't have much in that regard (Cells is probably the only one that'll look half-decent).

I'll let you know once I have something for you to try out.

Thanks for stopping by!

[qu4nt4r]

I also really should port some of the 2D LED matrix visualizers over, as right now CC.NET doesn't have much in that regard (Cells is probably the only one that'll look half-decent).

Thanks for your effort! Btw: Actually 1D and 2D look quite the same. On top there is a 8x128 matrix and at the bottom there is a 1x288 (144LED/m) strip under the stones.
Eager to further play around with CC and looking forward to further improvements. :)

[CaiB]

Ah, gotcha. When you said 2D matrix, I was expecting something more similar to this: https://youtu.be/s8qWqYTpCN4?t=52

[qu4nt4r]

Actually I also use the ws2812b LEDs. The difference should be the visualizer, assuming Charles uses the voronoi thing in the video. Just for another impression: Here is the cell one, once with time based enabled and once without. Its my shitty cam and the diffusers I use that may distort the impresion.

[CaiB]

Alright, I have a first version ready for you to test. Grab the latest autobuild, and edit your PacketUDP config section to look like this:

{
    "Type": "PacketUDP",
    "Name": "SampleUDP",
    "VisualizerName": "SampleLinear",
    "IP": "192.168.0.60",
    "Protocol": "TPM2.net",
    "Enable": true
},

(Override my name, visualizer, IP, etc with ones for your setup)

If needed, specify the port, but it will use the TPM2.net default (65506) if TPM2.net is selected and nothing else is configured. The default max packet size should also be compatible with your network MTUs, but you can lower it with a "MaxPacketLength": 1400, line.

I'm not 100% sure it's correct yet as there was something in the TPM2.net spec that didn't make sense to me, so I went with what was written but it may need to be changed.