This might help someone. I've spent a while trying to reduce unacceptable CPU load-induced flickering caused by using cheap FTDI USB to serial converters, such as the one I talked about on here last year (only 32-byte transmit buffer). Problems under Ubuntu 12.04 on three different laptops. I looked at the DMX USB plugin source and tried a few things which didn't help. I considered trying ftdi_sio instead of libftdi but that looked quite hard and with no guarantee of success.
So instead I built the [Open DMX Linux USB Driver module](http://www.erwinrol.com/open-dmx-usb-linux-driver/), which grabs the serial dongle so long as ftdi_sio is blacklisted, and creates /dev/dmx0. I tried symlinking /dev/dmx to this, which showed up in qlcplus as a DMX4Linux output, but trying to use that simply confused the module, requiring the dongle to be removed and plugged back in (as I found out below).
I then installed [OLA](http://www.opendmx.net/index.php/OLA_Debian_/_Ubuntu) which is very impressive with its web interface. It finds the "OpenDmx USB Device" output at /dev/dmx0 and has an ArtNet input (though I'm a bit concerned it's the assigned IP address rather than 127.0.0.1 or localhost). This plumbs straight through from qlcplus's new ArtNet plugin, and seems to result in much less propensity to flicker, plus of course would allow me to separate controller from DMX interface, wirelessly if needed. (With old laptops coming out of my ears and the unreasonably high price of proper DMX interfaces I could dedicate a netbook to driving the dongle, which ought to make things more reliable still.)
Thank you for the ArtNet interface!
Tip for better reliability with cheap interfaces
-
Matthew Marks
Just trying it on a 9 year old laptop (Pentium M 1.7GHz) while Firefox is playing a Flash video and it is so far rock steady. So much better than libftdi/DMX USB.
-
Massimo Callegari
Have you tried to change the output frequency as described in paragraph 3 of the DMX USB documentation ?
http://htmlpreview.github.io/?https://r ... utput.html
http://htmlpreview.github.io/?https://r ... utput.html
-
Matthew Marks
Hi Massimo. Yes I did try that, albeit by hacking the source code rather than the proper way you link to! It didn't make a noticeable difference. It was reporting that granularity was good, too. It's not a raw CPU power issue; instead, I think there's something fundamentally flawed about the way it does it. Regardless of the frame rate, you've still got user-space code which has to write 513 bytes from a software buffer into a device with a hardware buffer of only 32 bytes without that buffer emptying. That code could be interrupted by the scheduler for a period of longer than 32 bytes'-worth (minus all the USB latency etc which I read is quite an issue). It's scheduled as high priority but I read that doesn't have any effect in Linux and even if it did, I guess you'd have to find a way to run the main thread at lower priority as activities such as changing the view are enough to cause a flicker. (I tried nice-ing the application to top priority but that would have the same effect on all its threads and didn't help noticeably either.)
I'm no kernel expert, but I'm guessing that the OpenDmx module, being in kernel space, is better insulated from the scheduler and therefore any software buffer it contains is more responsive to the requirements of the serial converter.
Incidentally, the loop doesn't look thread safe to me - there is no mutex to lock access to the universe data array and other shared variables. (I did try a mutex, which again made no noticeable difference.) But then Qt might do something I don't know about.
I'm no kernel expert, but I'm guessing that the OpenDmx module, being in kernel space, is better insulated from the scheduler and therefore any software buffer it contains is more responsive to the requirements of the serial converter.
Incidentally, the loop doesn't look thread safe to me - there is no mutex to lock access to the universe data array and other shared variables. (I did try a mutex, which again made no noticeable difference.) But then Qt might do something I don't know about.
-
Matthew Marks
Update: as I suspected, this solution does not work when there is not a network. There is a "use_loopback" entry in /var/lib/ola/conf/ola-artnet-conf; setting this to "true" makes olad open an ArtNet input on 127.0.0.1 but qlcplus doesn't see this - should it be looking at the loopback interface too, perhaps optionally a la olad?
I have got it to work by setting up a dummy network as follows:
>echo 10.0.0.1 dummy >> /etc/hosts
modprobe dummy
ifconfig dummy0 dummy
olad then creates an ArtNet input on 10.0.0.1 and qlcplus sees this.
Incidentally, qlcplus segfaults on startup when this network is not present, until I change
>[outputmap]
universe0\plugin=ArtNet
back to "None".
Also, at one stage it had an entry something like
>[artnetplugin]
with the IP address previously assigned when on the network, and I couldn't see a way of getting it to forget this without removing the line(s) from the config file. Sorry, can't reproduce that.
I have got it to work by setting up a dummy network as follows:
>echo 10.0.0.1 dummy >> /etc/hosts
modprobe dummy
ifconfig dummy0 dummy
olad then creates an ArtNet input on 10.0.0.1 and qlcplus sees this.
Incidentally, qlcplus segfaults on startup when this network is not present, until I change
>[outputmap]
universe0\plugin=ArtNet
back to "None".
Also, at one stage it had an entry something like
>[artnetplugin]
with the IP address previously assigned when on the network, and I couldn't see a way of getting it to forget this without removing the line(s) from the config file. Sorry, can't reproduce that.
-
Matthew Marks
(To make the dummy interface persistent, add "dummy" to /etc/modules and add:
>auto dummy0
iface dummy0 inet static
address 10.0.0,1
netmask 255.0.0.0
to /etc/network/interfaces)
>auto dummy0
iface dummy0 inet static
address 10.0.0,1
netmask 255.0.0.0
to /etc/network/interfaces)