DiyLightAnimation
Software => xlights => Topic started by: sielbear on October 26, 2012,
-
I'm seeing an odd issue where LSP output is more fluid than xLights at the moment. This seems to happen for periods of complex changes. For example, when my matrix has heavy changes, the playback slows to updating perhaps once or twice / second. Wondering if anyone else is experiencing this. Sounds similar to the powerline topic above - wondering if the powerline adapter has nothing to do with it.
Again, if I playback the same complex segments out of LSP, the playback is MUCH more fluid. It seems to be limited to xLights / etherdongle.
Frank is looking at a few things in the conversions we are doing, and I'm also creating some additional test sequences / cases. Just wondering if I'm alone.
P.S., I'm using around 12k channels, so this may be something that only occurs in the higher channel count range.
-
Ok - I've ruled out complexity. Here is a sequence with 14 channels in use. Nothing but fades up and fades down, once per second (fade up for 1 second, fade down for 1 second.
Jerky xlights:
https://vimeo.com/52266385
LSP Smooth playback
https://vimeo.com/52265915
I tested by using franks conversion process to xLights AND by doing a conversion to LOR format out of LSP, setting the network properly (come one LSP, you gotta get this right), and playing back the LMS file from xlights. Playback is the same regardless of conversion process when xLights is outputting to etherdongle.
-
I'm experiencing the same thing using Vixen! Thank you for doing the videos. It saves me from standing in 20 degree weather tonight!
-
Well, now I feel bad for wearing Frank out about his crappy programming! :) Just kidding Frank!
But I've probably been working on this the past 24 hours. I initially thought my pixelnet strands were operating in hybrid mode because the lag was so bad. It turned out the fades were not slow enough to detect the issue I was seeing. (My test was to use sweeping fades across the house from different directions. I was fading across the strand too fast to realize what was going on.
And I'm also glad someone else is seeing this too!! My sanity is starting to return. It's nice to hear from someone else experiencing the same thing.
-
I have another couple of videos to post for demo...
Here is a slow fade from red to white over xlights - jerky... Video was still processing when I posted this. Should be completed in 5 minutes or so...
https://vimeo.com/52267409
And the slow fade in LSP - smooth playback:
https://vimeo.com/52267973
-
I've got packet captures between LSP and xLights for those curious. Definite differences between xLights and LSP output.
-
I started analyzing the xLights code to see if I could make sense of what might be going on here. I am starting to understand what Matt is doing but I cannot quite discern exactly what is going on here. I did notice that the gap between packets in the same universe (from Alan's packet captures) is around 60ms are slightly higher. I am wondering if this lag is introduced by the fact that with 32 networks he is running 32 distinct timers to handle all the packet generation.
It does appear that Matt only sends a packet for a universe if he needs to and skips them otherwise not sure how that works though.
Anyways that is what I have learned so far in my research. Just though I would share.
frank
P.S. No one has successfully run my conversions to conductor format yet. Without a conductor of my own I cannot test what I am generating. Hopefully we can sort that out and get the conductor conversion process working soon.
-
I'm trying to reproduce the issue, but have not been successful. I have 1998 channels of smartstrings set up inside and whether I drive them with USB pixelnet or the Etherdongle, I cannot perceive any difference. For my Etherdongle setup, I just plug the cable directly from the Etherdongle to the RJ45 jack on my laptop (no ethernet hubs or switches).
If you can help me narrow down the issue, I would be happy to make the necessary code fixes. Cheers,
Matt
-
Hi Matt,
Are you doing the testing with a full 32 DMX universes configured? I am thinking that could be a contributing factor. I personally have not seen the behavior myself as I do not have a full setup yet. Alan (sielbear) has seen this in a full production environment. Perhaps he can provide some insight.
If you want to pour over the packet capture let me know and I can add you to the dropbox.
Regards,
Frank
-
Was the 14 channel example shown in the video still driving 32 universes in xLights?
Matt
-
That is my understanding but I would need Alan to say 100% for sure...
Frank
-
Did you save to the xLights format first? xLights format should be much more efficient.
Might want to try the following utility to see what values are being sent and the frame rate.
http://sacnview.sourceforge.net/
-
OK, I have a version of xLights that I can drive 32 universes with --
and I can confirm that xLights is not operating at full speed. So the good news is that I can reproduce the problem now. I don't have a solution yet, but at least I have an environment I can test with. I will keep you updated with my progress.
Matt
Update 1: Well I was able to send out a full 32 universes to the Etherdongle with no slow-down. Network utilization went up to about 2.7%. But I measured the time being taken by the code in the 50msec timer and it was only 1-2 msec. So I am back to square one - I am not able to reproduce the issue.
-
Thanks Matt!
I hope to have a full setup available by the end of the weekend to do some testing with. Could very well be in my translation code but a couple of people in this thread mentioned the same behavior starting from Vixen and going through the xLights conversion.
Frank
-
To confirm, I am sending a full 32 universe setup.
I can see significant differences between xLights and LSP, however, I believe Frank has an updated version to use for some fades. I'm seeing the oddness with the fades. Perhaps this will help some:
I accidentally left xlights up (in the background, NO SHOW RUNNING) and had LSP running with output enabled. I got some REALLY odd flashes - confused the heck out of me at first until I realized xLights was sending a '0' packet every second or twice a second - something around that frequency. The slow refresh rate I'm seeing was VERY similar to the light blink interval I was seeing when LSP and xLights was running. It was almost like xLights was sending packets at the same rate the "idle" packets are sent... Make sense?
This was for a slow fade from the left side of the house to the right - fading from white to red. Again, this fade is very smooth in LSP.
I will use the new conversion tool from Frank tonight and confirm for you! Thank you so much for your help!
-
I was having the same jerky response here, and it was happening even when I removed LSP from the mix and just used the xLights RGB cycle "Mixed Colors" test on my etherdongle-connected pixels. My E681-connected pixels were nice and smooth, but my etherdongle pixels were pretty jerky (about one update per 1/2 second).
I discovered that the issue was due to a bug in the etherdongle firmware, as referenced here: http://diylightanimation.com/index.php?topic=10223.0
As soon as I added another channel in the 1-512 range to the RGB cycle Mixed Colors test, everything turned real smooth.
As a work-around, I'm planning on adding a bunch of ramp up/down stuff to one of my unused channels in the 1-512 range within LSP.
Just thought I'd share this, as perhaps the mysterious jerky response others were seeing as described in this thread was actually caused by the same thing.
Andy
-
I was having the same jerky response here, and it was happening even when I removed LSP from the mix and just used the xLights RGB cycle "Mixed Colors" test on my etherdongle-connected pixels. My E681-connected pixels were nice and smooth, but my etherdongle pixels were pretty jerky (about one update per 1/2 second).
I discovered that the issue was due to a bug in the etherdongle firmware, as referenced here: http://diylightanimation.com/index.php?topic=10223.0
As soon as I added another channel in the 1-512 range to the RGB cycle Mixed Colors test, everything turned real smooth.
As a work-around, I'm planning on adding a bunch of ramp up/down stuff to one of my unused channels in the 1-512 range within LSP.
Just thought I'd share this, as perhaps the mysterious jerky response others were seeing as described in this thread was actually caused by the same thing.
Andy
Thanks for the figuring this out! I was able to replicate and solve the issue with this information. The fix will be in the next release of xLights.
Matt