## Wacom Cintiq 16 on Debian Stretch

15.02.2019 18:47

Wacom Cintiq 16 (DTK-1660/K0-BX) is a drawing tablet that was announced late last year. At around 600€ I believe it's now the cheapest tablet with a display you can buy from Wacom. For a while I've been curious about these things, but the professional Wacoms were just way too expensive and I wasn't convinced by the cheaper Chinese alternatives. I've been using a small Intuos tablet for several years now and Linux support has been flawless from the start. So when I recently saw the Cintiq 16 on sale at a local reseller and heard there are chances that it will work similarly well on Linux I couldn't resist buying one.

Even though it's a very recent device, the Linux kernel already includes a compatible driver. Regardless, I was prepared for some hacking before it was usable on Debian. I was surprised how little was actually required. As before, the Linux Wacom Project is doing an amazing job, even though Linux support is not officially acknowledged by Wacom as far as I know.

The tablet connects to the computer using two cables: HDMI and USB. HDMI connection behaves just like a normal 1920x1080 60 Hz flat panel monitor and the display works even if support for everything else is missing on the computer side. The HDMI cable also caries an I2C connection that can be used to adjust settings that you would otherwise expect in a menu accessible by buttons on the side of a monitor (aside from a power button, the Cintiq itself doesn't have any buttons).

After loading the i2c-dev kernel module, the ddcutil version 0.9.4 correctly recognized the display. The i2c-2 bus interface in the example below goes through the HDMI cable and was in my case provided by the radeon driver:

$ddcutil detect Display 1 I2C bus: /dev/i2c-2 EDID synopsis: Mfg id: WAC Model: Cintiq 16 Serial number: ... Manufacture year: 2018 EDID version: 1.3 VCP version: 2.2$ ddcutil --bus=2 capabilities
MCCS version: 2.2
Commands:
Command: 01 (VCP Request)
Command: 02 (VCP Response)
Command: 03 (VCP Set)
Command: 07 (Timing Request)
Command: f3 (Capabilities Request)
VCP Features:
Feature: 02 (New control value)
Feature: 04 (Restore factory defaults)
Feature: 05 (Restore factory brightness/contrast defaults)
Feature: 08 (Restore color defaults)
Feature: 12 (Contrast)
Feature: 13 (Backlight control)
Feature: 14 (Select color preset)
Values:
04: 5000 K
05: 6500 K
08: 9300 K
0b: User 1
Feature: 16 (Video gain: Red)
Feature: 18 (Video gain: Green)
Feature: 1A (Video gain: Blue)
Feature: AC (Horizontal frequency)
Feature: AE (Vertical frequency)
Feature: B2 (Flat panel sub-pixel layout)
Feature: B6 (Display technology type)
Feature: C8 (Display controller type)
Feature: C9 (Display firmware level)
Feature: CC (OSD Language)
Values:
02: English
03: French
04: German
05: Italian
06: Japanese
07: Korean
08: Portuguese (Portugal)
09: Russian
0a: Spanish
0d: Chinese (simplified / Kantai)
14: Dutch
1e: Polish
26: Unrecognized value
Feature: D6 (Power mode)
Values:
01: DPM: On,  DPMS: Off
04: DPM: Off, DPMS: Off
Feature: DF (VCP Version)
Feature: E1 (manufacturer specific feature)
Values: 00 01 02 (interpretation unavailable)
Feature: E2 (manufacturer specific feature)
Values: 01 02 (interpretation unavailable)
Feature: EF (manufacturer specific feature)
Values: 00 01 02 03 (interpretation unavailable)
Feature: F2 (manufacturer specific feature)


I didn't play much with these settings, since I found the factory setup sufficient. I did try out setting white balance and contrast and the display responded as expected. For example, to set the white balance to 6500K:

$ddcutil --bus=2 setvcp 14 5 Behind the USB connection is a hub and two devices connected to it: $ lsusb -s 1:
Bus 001 Device 017: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 001 Device 019: ID 056a:0390 Wacom Co., Ltd
Bus 001 Device 016: ID 056a:0395 Wacom Co., Ltd
$dmesg ... usb 1-6: new high-speed USB device number 20 using ehci-pci usb 1-6: New USB device found, idVendor=056a, idProduct=0395, bcdDevice= 1.00 usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-6: Product: Cintiq 16 HUB usb 1-6: Manufacturer: Wacom Co., Ltd. hub 1-6:1.0: USB hub found hub 1-6:1.0: 2 ports detected usb 1-6.2: new high-speed USB device number 21 using ehci-pci usb 1-6.2: New USB device found, idVendor=0403, idProduct=6014, bcdDevice= 9.00 usb 1-6.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-6.2: Product: Single RS232-HS usb 1-6.2: Manufacturer: FTDI ftdi_sio 1-6.2:1.0: FTDI USB Serial Device converter detected usb 1-6.2: Detected FT232H usb 1-6.2: FTDI USB Serial Device converter now attached to ttyUSB0 usb 1-6.1: new full-speed USB device number 22 using ehci-pci usb 1-6.1: New USB device found, idVendor=056a, idProduct=0390, bcdDevice= 1.01 usb 1-6.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-6.1: Product: Cintiq 16 usb 1-6.1: Manufacturer: Wacom Co.,Ltd. usb 1-6.1: SerialNumber: ... input: Wacom Cintiq 16 Pen as /devices/pci0000:00/0000:00:1a.7/usb1/1-6/1-6.1/1-6.1:1.0/0003:056A:0390.000D/input/input62 on usb-0000:00:1a.7-6.1/input0  056a:0395 is the hub and 056a:0390 is the Human Interface Device class device that provides the actual pen input. When the tablet is off but connected to power, the HID disconnects but other two USB devices are still present on the bus. I'm not sure what the UART is for. This thread on GitHub suggests that it offers an alternative way of interfacing with the I2C bus for adjusting the display settings. On the stock 4.9.130 kernel that comes with Stretch the pen input wasn't working. However, the 4.19.12 kernel from stretch-backports correctly recognizes the devices and as far as I can see works perfectly. $ cat /proc/version
Linux version 4.19.0-0.bpo.1-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.19.12-1~bpo9+1 (2018-12-30)


I'm using the stock GNOME 3.22 desktop that comes with Stretch. After upgrading the kernel, the tablet correctly showed up in the Wacom Tablet panel in gnome-control-center. Pen settings there also work and I was able to calibrate the input using the Calibrate button. Calibration procedure instructs you to press the pen onto targets shown on the display and looks exactly like when using official software on Mac OS.

In GIMP I had to enable the new input devices under Edit, Input Devices and set them to Screen mode, same as with other tablets. You get two devices: one for the pen tip and another one for when you turn the pen around and use the other eraser-like end. These two behave like independent devices in GIMP, so each remembers its own tool settings.

As far as I can see, pen pressure, tilt angle and the two buttons work correctly in GIMP. The only problem I had is that it's impossible to do a right-click on the canvas to open a menu. This was already unreliable on the Intuos and I suspect it has to do with the fact that the pen always moves slightly when you press the button (so GIMP registers click-and-drag rather than a click). With the higher resolution of the Cintiq it makes sense that it's even harder to hold the pen still enough.

Otherwise, GIMP works mostly fine. I found GNOME to be a bit stubborn about where it wants to place new dialog windows. If I have a normal monitor connected alongside the tablet, file and color chooser dialogs often end up on the monitor instead of the tablet. Since I can't use the pen to click on something on the monitor, it forces me to reach for the mouse, which can be annoying.

I've noticed that GIMP sometimes lags behind the pen, especially when dragging the canvas with the middle-click. I didn't notice this before, but I suspect it has to do with the higher pen resolution or update rate of the Cintiq. The display also has a higher resolution than my monitor, so there are more pixels to push around. In any case, my i5-750 desktop computer will soon be 10 years old and is way overdue for an upgrade.

In conclusion, I'm very happy with it even if it was a quite an expensive gadget to buy for an afternoon hobby. After a few weeks I'm still getting used to drawing onto the screen and tweaking tool dynamics in GIMP. The range of pressures the pen registers feels much wider than on the Intuos, although that is probably very subjective. To my untrained eyes the display looks just amazing. The screen is actually bigger than I thought and since it's not easily disconnectable it is forcing me to rethink how to organize my desk. In the end however, my only worry is that my drawing skills are often not on par with owning such a powerful tool.

Posted by | Categories: Life | Comments »

08.02.2019 11:57

It recently came to my attention that Google has a new Search Console where you can see the status of your web site in Google's search index. I checked out what it says for this blog and I was a bit surprised.

Some things I expected, like the number of pages I've blocked in the robots.txt file to prevent crawling (however I didn't know that blocking an URL there means that it can still appear in search results). Other things were weirder, like this old post being soft recognized as a 404 Not Found response. My web server is properly configured and quite capable of sending correct HTTP response codes, so ignoring standards in that regard is just craziness on Google's part. But the thing that caught my eye the most was the number of Excluded pages on the Index Coverage pane:

Considering that I have less than a thousand published blog posts this number seemed high. Diving into the details, it turned out that most of the excluded pages were redirects to canonical URLs and Atom feeds for post comments. However at least 160 URL were permalink addresses of actual blog posts (there may be more, because the CSV export only contains the first 1000 URLs).

All of these were in the "crawled, not indexed" category. In their usual hand-waving way, Google describes this as:

The page was crawled by Google, but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling.

I read this as "we know this page exists, there's no technical problem, but we don't consider it useful to show in search results". The older the blog post, the more likely that it was excluded. Google's index apparently contains only around 60% of my content from 2006, but 100% of that published in the last couple of years. I've tried searching for some of these excluded blog posts and indeed they don't show in the results.

I have no intention to complain about my early writings not being shown to Google's users. As long as my web site complies with generally accepted technical standards I'm happy. I write about things that I find personally interesting and what I earnestly believe might be useful information in general. I don't feel entitled to be shown in Google's search results and what they include in their index or not is their own business.

That said, it did made me think. I'm using Google Search almost exclusively to find information on the web. I suspected that they heavily prioritize new over old, but I've never seriously considered that Google might be intentionally excluding parts of the web from their index altogether. I often hear the sentiment how the old web is disappearing. That the long tail of small websites is as good as gone. Some old one-person web sites may indeed be gone for good, but as this anecdote shows, some such content might just not be discoverable through Google.

All this made me switch my default search engine in Firefox to DuckDuckGo. Granted I don't know what they include or exclude from their search either. I have yet to see how well it works, but maybe it isn't such a bad idea to go back to the time where trying several search engines for a query was a standard practice.

Posted by | Categories: Life | Comments »

## Notes on MightyWatt electronic load

02.02.2019 14:43

MightyWatt is a small, computer controlled electronic DC load made by Jakub Polonský. I recently ordered one for work, since I often need to test power supplies and it was significantly cheaper than a similar professional desktop instrument. I was first looking for a Re:load Pro, since I have been very happy with the old analog Re:load, however it turns out they are out of stock and impossible to get. MightyWatt was the closest alternative that fit the budget. After several months, here is a quick review and some notes on how well it performs in practical use.

Compared to Re:load, MightyWatt is not a stand-alone device. It comes in the form of an Arduino shield and you need to mount it on an Arduino Uno (or a compatible) microcontroller board. You also need to compile an open source firmware yourself and program the board with it. The ATmega328 on the Arduino then controls the load and communicates with the computer you connect to its USB port.

It's also worth mentioning that this design already has quite a history. First revision apparently shipped in 2014. I am using revision 3 hardware from 2017 and latest software from GitHub. During these tests I was using an Arduino-knockoff called Smduino. To protect the computer from any mishaps with the load, I'm connecting it over an Olimex USB-ISO USB isolator.

The initial setup went quite smoothly. The instructions on how to program the firmware using the Arduino IDE were nice and clear. After your order, the author commits the calibration file for your serial number to GitHub, which I thought was a nice approach. The control program for Windows has a pre-compiled build in the GitHub repo, so there is no need to install Visual Studio, unless you want to compile it from the C# source yourself.

In contrast to the straightforward software instructions I could find no illustration showing how to actually mount the device onto the Arduino board and initially I was a bit baffled. The 100 mil male headers on the MightyWatt are missing pins from the standard Arduino shield layout, so it's possible to fit them into the sockets in several possible ways. I'm guessing only one of those doesn't end in disaster. In the end I noticed the (very) tiny pin markings on the MightyWatt silk-screen and matched them with the corresponding pins on the Arduino.

Unfortunately, the headers are also the only thing that keeps MightyWatt mechanically connected to the Arduino. Beefy measurement cables are commonplace when working with large currents and the stiffness of the headers alone just isn't enough to keep the MightyWatt securely connected to the Arduino. On several occasions I found that I have pulled it off when messing with the cabling. I was looking into 3D-printing an enclosure, however this MightyWatt PCB doesn't have any spare holes for additional screws, so it's not easy to work around this issue. It seems that an acrylic case existed at one point, but I couldn't find it for sale and since it doesn't seem to screw onto the PCB I'm not sure it would help.

Comparing MightyWatt current readout to VC220. VC220 was in series with MightyWatt current terminals. The load was in constant current mode and was connected to a 5 V power supply.

Comparing MightyWatt voltage readout to VC220. The load was in 4-point mode with a lab power supply connected to the voltage terminals. Current terminals were not connected.

As far as accuracy and calibration is concerned, I can't be certain since I don't have any good reference to compare it to. After some simple experiments with a VC220 multimeter it seems reasonable, as you can see on the graphs above. The current readout on the MightyWatt is with-in the measurement tolerance of the VC220 for the complete 10 A range. Voltage readout does fall outside of the tolerance of VC220. I don't know whether that is a fault of VC220 or MightyWatt, but in any case, both devices only disagree for about 1% and linearity looks good.

One problem I noticed with constant current setting was that there seems to be a momentary glitch when changing the set point with the load running (i.e. without stopping it). This seems to trigger some fast over-current protections, even when currents should be well below the limit. For example, changing the load from 1 A to 2 A sometimes puts a 3 A supply into foldback mode, but doing the same by stopping the load for the change doesn't.

I really like the fact that MightyWatt supports 4-point Kelvin measurements. The software also supports a mode called Simple ammeter, which puts current inputs into minimum resistance. Combined with the 4-point setting, this converts MightyWatt into a computer-controlled ampere- and voltmeter pair. I have not tried this mode yet, but it sounds like it might be useful as a simple power meter.

Other than that, I haven't looked much into the electronics design. However the author has a blog with many interesting posts on the design of the MightyWatt if you are interested in the details.

The Windows software is functional, if somewhat buggy at times. Unfortunately as far as I can see, there is no way to control MightyWatt from Linux at the moment. I would love to automate my measurements with Python, like I've been doing with everything else. Fortunately, the Windows control program allows you do some simple scripting, so that is not that much of a pain. Also, the communications protocol seems well documented and I just might write a Python library for it eventually.

My biggest issue with the software is that the Windows control program seems to often lose connection with the load. This isn't handled gracefully and I often find that it will no longer see the MightyWatt's COM port after that. This then requires some ritual of reconnecting the USB cable and restarting the application to get it working again.

I'm not sure what is the reason for this and I don't know whether this is a software problem on Windows side or whether the Arduino firmware is crashing. First I was blaming electrical interference, since it appeared to often happen when I connected an oscilloscope probe to a supply I was testing. Then I thought the USB isolator was causing it. However after some more testing I found that this still randomly happens even if I just let the MightyWatt run idle, directly connected with a USB cable to a PC.

In conclusion, it's a nice little instrument for its price, especially considering that similar instruments can easily cost an order of a magnitude more. I like that it comes tested and calibrated out of the box and that it's well documented. I really like the open source aspect of it and I always find it hard to criticize such projects without submitting patches. The Windows control software is pretty powerful and can support a lot of different measurements. The ugly part is the flimsy mechanical setup and the connection reliability problem, which means that I can't leave a measurement running without being constantly present to check for errors.

Posted by | Categories: Analog | Comments »

## Measuring THD on Denon RCD-M41DAB

26.01.2019 21:53

Around a month ago my old micro Hi-Fi system wouldn't turn on. I got a Sony CMT-CP11 as a gift from my parents way back in 2000 and it had served me well. I really liked the fact that I had a service manual for it with complete schematic, and over the years it accumulated a few hacks and fixes. It did start to show its age though. For example, the original remote no longer works because its phenolic paper-based PCB had deteriorated.

Unfortunately, it seems that now the mains transformer had died as well. I spent some time searching around the web for a replacement, but couldn't find any. I contemplated rewinding it, but doing that on a mains transformer seemed too risky. Finally, I gave up and just bought a new system (however, if anyone knows a source for a Sony part 1-435-386-11 or 1-435-386-21 I would still be interested in buying one).

So anyway, now I'm an owner of a shiny new Denon RCD-M41DAB. In its manual, it states that the output amplifier is rated as:

Image by D&M Holdings Inc.

This a bit less than CMT-CP11, which was rated 35 W at the same conditions. Not that I care too much about that. I doubt that I ever cranked the Sony all the way to full volume and I'm not very sensitive to music quality. Most of my music collection is in lossy compressed files anyway. However, I was still curious if Denon meets these specs.

Unfortunately I didn't have big enough 6 Ω resistors at hand to use as dummy loads. I improvised with a pair of 8 Ω, 60 W banks I borrowed from my father. I connected these across the speaker outputs of the Denon and connected a scope probe over the left one.

To provide the input signal I used the Bluetooth functionality of the RCD-M41DAB. I paired my phone with it and used the Keuwlsoft function generator app to feed in a sine wave at 1 kHz. I set the app to 100% amplitude, 100% volume and also set 100% media volume in the Android settings. I then set the volume by turning the volume knob on the RCD-M41DAB.

The highest RCD-M41DAB volume setting before visible distortion was 33. This produced a peak-to-peak signal of 37.6 V and a power of around 22 W on the 8 Ω load:

Using the FFT function of the oscilloscope it was possible to estimate total harmonic distortion at these settings:

THD = \frac{U_3}{U_1} \cdot 100\% = 0.3\%

For comparison, I also measured the THD at the unloaded line output of a cheap Bluetooth receiver. I used the same app and measurement method and that came at 0.07% THD.

The next higher volume setting on RCD-M41, 34, was visibly clipped at around 39 V peak-to-peak:

I achieved the rated 30 W (albeit at 8 Ω, not 6 Ω) at volume setting 36. At that point the signal was badly clipped, producing many visible harmonics on the FFT display:

Calculated THD at this output level (including up to 7th harmonic) was 12.9%

So what can I conclude from these measurements? First of all, I was measuring the complete signal path, from DAC onward, not only the output stage. Before saturating the output I measured 0.3 % THD at 22 W, which I think is excellent. According to this article, 1% THD is around the level detectable by an untrained human ear. I couldn't achieve 30 W at 10% THD. However, I wasn't measuring at the specified 6 Ω load.

If I assume that the output stage would saturate at the same peak-to-peak voltage at 6 Ω load as it did at 8 Ω, then it would output 32 W at a similar distortion. This would put it well below the specified 10% THD. Whether this is a fair assumption is debatable. I think the sharply clipped waveforms I saw suggest that most of the distortion happens when the output stage supply voltage is reached and this is mostly independent of the load.

That said, the volume setting I found comfortable for listening to music is around 10, so I'm pretty sure I won't ever be reaching the levels where distortion becomes significant.

Posted by | Categories: Analog | Comments »

## Jahresrückblick

19.01.2019 20:07

And so another year rushed by. In the past twelve months I've published 19 blog posts, written around 600 notebook pages and read 13 books.

Perhaps the largest change last year was that I left my position at the Department of communication systems at the Jožef Stefan Institute. After 7 years behind the same desk I really needed a change in the environment and I already switched to working only part-time the previous fall. This year I only planned to handle closing work on an EU project that was spinning down. I found it hard to do meaningful research work while working on other things most of the week anyway.

Even though I led my project work to official (and successful) completion I feel like I left a lot of things undone there. There are interesting results left unpublished, hardware forgotten, and not the least my PhD work which got kind of derailed over the course of the last project and was left in some deep limbo with no clear way of getting out. I thought that by stepping away of it all for a few months I will get a clearer perspective on what exactly I want to do with all of this. I miss research work, I don't miss the politics and I have yet to come to any conclusion if and how to proceed.

As a kind of ironic twist, I also unexpectedly got first authorship of a scientific paper last year. According to git log, it took almost exactly 4 years and around 350 commits and it tells a story quite unlike what I initially had in my mind. After countless rejections from various journals I basically gave up on the last submission going through. It was accepted for publication pending more experimental work, which caused a crazy month of hunting down all the same equipment from years ago, spending weekends and nights in the lab and writing up the new results.

I spent most of the rest of my work days at Klevio wearing an electrical engineer's hat. Going from a well equipped institute back to a growing start-up brought new challenges. I was doing some programming and a lot of electronics design and design for manufacture, a field I barely touched with my electronics work at the Institute. In contrast to my previous RF work, here I brushed up on my analog audio knowledge and acoustics. I discovered the joy of meeting endless electromagnetic compatibility requirements for consumer devices.

Not surprisingly, after this I was not doing a lot of electronics in my spare time. I have several hardware projects in a half-finished state still left over from a year ago. I wish to work more on them this year and hopefully also write up some interesting blog posts. Similarly, I was not doing a lot of open source work, short of some low-effort maintenance of my old projects. Giving my talk about developing GIMP plug-ins was an absolute pleasure and definitely the most fun presentation to prepare last year.

Drawing has remained my favorite pass-time and a way to fight anxiety, although I sometimes feel conflicted about it. I did countless sketches and looking back I'm happy to see my drawing has improved. I made my first half-way presentable animated short. It was nice to do such a semi-long project from start to completion, although it sometimes started to feel too much like a yet another afternoon job. I have some more ideas and with everything I learned last year I think it would be fun to try my hand at animating something more original, if only I could manage a more relaxed schedule for it.

All in all, looking back at my notes suggests it wasn't such a bad year. Except maybe December, which tends to be the most depressing month for me anyway. As last time, I'm not making any big plans for this year. I'm sure it will be again too short to clear out my personal backlog of interesting things to do and everything else that will want to happen before 2020. I only hope to waste less of it on various time-sinks like Hacker News and other addictive brain candy web sites. These seem to be starting to eat up my days despite my trying to keep my distance.

Posted by | Categories: Life | Comments »

## Going to 35c3

12.12.2018 19:03

Just a quick note that I've managed to get a ticket for this year's Chaos Communications Congress. So I'll be in Leipzig at the end of the month, in case anyone wants to have a chat. I don't have anything specific planned yet. I haven't been at the congress since 2015 and I don't know how much has changed in the past years since it moved from Hamburg. I've selected some interesting talks on Halfnarp, but I have a tentative plan to spend more time talking with people than camping in the lecture halls. Drop me an email or possibly tweet to @avian2 if you want to meet.

Posted by | Categories: Life | Comments »

## Notes on using GIMP and Kdenlive for animation

08.12.2018 12:01

This summer I made a 60-second hand-drawn animation using GIMP and Kdenlive. I thought I might write down some notes about the process I used and the software problems I had to work around. Perhaps someone else considering a similar endeavor will find them useful.

For sake of completion, the hardware I used for image and video editing was a Debian GNU/Linux system with 8 GB of RAM and an old quad-core i5 750 CPU. For drawing I used a 7" Wacom Intuos tablet. For some rough sketches I also used an old iPad Air 2 with Animation Creator HD and a cheap rubber finger-type stylus. Animation Creator was the only proprietary software I used.

I drew all the final animation cels in GIMP 2.8.18, as packaged in Debian Stretch. I've used my Onion Layers plug-in extensively and added several enhancements to it as work progressed: It now has the option to slightly color tint next and previous frames to emphasize in which direction outlines are moving. I also added new shortcuts for adding a layer to all frames and adding a new frame. I found that GIMP will quite happily work with images with several hundreds of layers in 1080p resolution and in general I didn't encounter any big problems with it. The only thing I missed was an easier way to preview the animation with proper timings, although flipping through frames by hand using keyboard shortcuts worked quite well.

For some of the trickier sequences I used the iPad to draw initial sketches. The rubber stylus was much too imprecise to do final outlines with it, but I found drawing directly on the screen more convenient for experimenting. I later imported those sketches into GIMP using my Animation Creator import plug-in and then drew over them.

A cel naively colored using Bucket Fill (left), manually using the Paintbrush Tool (middle) and using the Color Layer plug-in (right).

I've experimented quite a bit with how to efficiently color-in the finished outlines. Normal Bucket Fill leaves transparent pixels if used on soft anti-aliased outlines. The advice I got was to color the outlines manually with a Paintbrush Tool, but I found that much too time consuming. In the end I made a quick-and-ugly plug-in that helped automate the process somewhat. It used thresholding to create a sharp outline on a layer beneath the original outline. I then used Bucket Fill on that layer. This preserved somewhat the the quality of the initial outline.

I mostly used one GIMP XCF file per scene for cels and one file for the backgrounds (some scenes had multiple planes of backgrounds for parallax scrolling). I exported individual cels using the Export Layers into transparent-background PNG files. For the scene where I had two characters I later wished that I had one XCF file per character since that would make it easier to adjust timing.

I imported the background and cels into Kdenlive. Backgrounds were simple static Image Clips. For cels I mostly used Slideshow Clips with a small frame duration (e.g. 3 frame duration for 8 frames per second). For some scenes I instead imported individual cels separately as images and dragged them manually to the timeline if I wanted to adjust timing of individual cels. That was quite time consuming. The cels and backgrounds were composited using a large number of Composite & Transform transitions.

I was first using Kdenlive 16.12.2 as packaged by Debian but later found it too unstable. I switched to using the 18.04.1 AppImage release from the Kdenlive website. Switching versions was painful, since the project file didn't import properly in the newer version. Most transitions were wrong, so I had to redo much of the editing process.

I initially wanted to do everything in one monolithic Kdenlive project. However this proved to be increasingly inconvenient as work progressed. Even 18.04.1 was getting unstable with a huge number of clips and tracks on the timeline. I also was having trouble properly doing nice-looking dissolves between scenes that involved multiple tracks. Sometimes seemingly independent Composite & Transforms were affecting each other in unpredictable ways. So in the end I mostly ended up with one Kdenlive project per scene. I rendered each such scene to a lossless H.264 and then imported the rendered scenes into a master Kdenlive project for final editing.

Regarding Kdenlive stability, I had the feeling that it doesn't like Color Clips for some reason, or transitions to blank tracks. I'm not sure if there's really some bug or it was just my imagination (I couldn't reliably reproduce any crash that I encountered), but it seemed that the frequency of crashes went down significantly when I put one track with an all-black PNG at the bottom of my projects.

In general, the largest problem I had with Kdenlive was an issue with scaling. My Kdenlive project was 720p, but all my cels and backgrounds were in 1080p. It appeared that sometimes Composite & Transform would use 720p screen coordinates and sometimes 1080p coordinates in unpredictable ways. I think that the renderer implicitly scales down the bottom-most track to the project size, if at some point in time it sees a frame larger than the project size. In the end I couldn't figure the exact logic behind it and I had to resort to randomly experimenting until it worked. Having separate, simpler project files for each scene helped this significantly.

Frame scaled explicitly from 1080p to 720p using Composite & Transform (left) and scaled implicitly during rendering (right).

Another thing I noticed was the the implicit scaling of video tracks seemed to use lower-quality scaling algorithm than the Composite & Transform, resulting in annoying visible changes in image quality. In the end, I forcibly scaled all tracks to 720p using an extra Composite & Transform, even when one was not explicitly necessary.

Comparison of luminosity during a one second transition from a dark scene to black between Fade to black effect and Composite & Transform transition. Fade to black reaches black faster than it should, but luminosity does not jump up and down.

I was initially doing transitions between scenes using the Composite & Transform because I found adjusting the alpha values through keyframes more convenient than setting lengths of Fade to/from black effects. However I noticed that the Composite & Transform seems to have some kind of a rounding issue and transitions using it were showing a lot of bands and flickering in the final render. In the end I switched to using Dissolves and Fade to/from black which looked better.

Finally, some minor details about video encoding I learned. The H.264 quality setting in Kdenlive (CRF) is inverted. Lower values mean higher quality. H.264 uses YUV color space, while my drawings were in RGB color space. After rendering the final video some shades of gray got a bit of a green tint, which was due to the color space conversion in Kdenlive. As far as I know there is no way to help with that. GIMP and PNG only support RGB. In any case, that was quite minor and I was assured that I only saw it since I was starting at these drawings for so long.

How to sum this up? Almost every artist I talked with recommended using proprietary animation software and was surprised when I told them what I'm using. I think in general that is reasonable advice (although the prices of such software seem anything but reasonable for a summer project). I was happy to spend some evenings writing code and learning GIMP internals instead of drawing, but I'm pretty sure that's more an exception than the rule.

There were certainly some annoyances that made me doubt my choice of software. Redoing all editing after switching Kdenlive versions was one of those things. Other things were perhaps just me being too focused on minor technical details. In any case, I remember doing some projects with Cinelerra many years ago and I think Kdenlive is a quite a significant improvement over it in terms of user interface and stability. Of course, neither GIMP nor Kdenlive were specifically designed for this kind of work (but I've heard Krita got native support for animations, so it might be worth checking out). If anything, the fact that it was possible for me to do this project shows how flexible open source tools can be, even when they are used in ways they were not meant for.

Posted by | Categories: Life | Comments »

## A summer animation project

30.11.2018 22:19

In December last year I went to an evening workshop on animation that was part of the Animateka festival in Ljubljana. It was fascinating to hear how a small group of local artists made a short animated film, from writing the script and making a storyboard to the final video. Having previously experimented with drawing a few seconds worth of animation in GIMP I was tempted to try at least once to go through this entire process and try to animate some kind of story. Not that I hoped to make anything remotely on the level that was presented there. They were professionals winning awards, I just wanted to do something for fun.

Unfortunately I was unable to attend the following workshops to learn more. At the time I was working for the Institute, wrapping up final months of an academic project, and at the same time just settling into an industry job. Between two jobs it was unrealistic to find space for another thing on my schedule.

I played with a few ideas here and there and thought I might prepare something to discuss at this year's GalaCon. During the Easter holidays I took a free week and being somewhat burned out I didn't have anything planned. So I used the spare time to step away from the life of an electrical engineer and come up with a short script based on a song I happened to randomly stumble upon on YouTube some weeks before. I tried to be realistic and stick as much as possible to the things I felt confident I could actually draw. By the end of the week I had a very rough 60-second animatic that I nervously shared around.

At the time I doubted I would actually do the final animation. I was encouraged by the responses I got to the script, but I didn't previously take notes on how much time it took me to do one frame of animation. So I wasn't sure how long it would take to complete a project like that. It just looked like an enormous pile of cels to draw. And then I found in my inbox a mail saying my scientific paper that I had unsuccessfully tried to publish for nearly 4 years got accepted pending a major revision and everything else was put on hold. It was another mad dash to repeat the experiments, process the measurements and catch the re-submission deadline.

By June my work at the Institute ended and I felt very much tired and disappointed and wanted to do something different. With a part of my week freed up I decided to spend the summer evenings working on this animation project I came up with during Easter. I went through some on-line tutorials to refresh my knowledge and, via a recommendation, bought the Animator's Survival Kit book, which naturally flew completely over my head. By August I was able to bother some con-goers in Ludwigsburg with a more detailed animatic and one fully animated scene. I was very grateful for the feedback I got there and found it encouraging that people were seeing some sense in all of it.

At the end of the summer I had the wall above my desk full of scraps and of course I was nowhere near finished. I underestimated how much work was needed and I was too optimistic in thinking that I will be able to dedicate more than a few hours per week on the project. I scaled back my expectations a bit and I made a new, more elaborate production spreadsheet. The spreadsheet said I'll finish in November, which in the end actually turned out to be a rather good estimate. The final render landed on my hard disk on the evening of 30 October.

So here it is, a 60 second video that is the result of about 6 months of on-and-off evening work by a complete amateur. Looking at it one month later, it has unoriginal character design obviously inspired by the My Little Pony franchise. I guess not enough to appeal to the fans of that show and enough to repel everybody else. There's a cheesy semblance of a story. But it means surprisingly much to me and I probably would never finish it if I went with something more ambitious and original.

I've learned quite a lot about animation and video editing. I also wrote quite a bit of code for making this kind of animation possible using a completely free software stack and when time permits I plan to write another post about the technical details. Perhaps some part of my process can be reused by someone with a bit more artistic talent. In the end it was a fun, if eventually somewhat tiring, way to blow off steam after work and reflect on past decisions in life.

(Click to watch Home where we are video)

Posted by | Categories: Life | Comments »

## The case of disappearing PulseAudio daemon

03.11.2018 19:39

Recently I was debugging an unusual problem with the PulseAudio daemon. PulseAudio handles high-level details of audio recording, playback and processing. These days it is used by default in many desktop Linux distributions. The problem I was investigating was on an embedded device using Linux kernel 4.9. I relatively quickly I found a way to reproduce it. However finding the actual cause was surprisingly difficult and led me into the kernel source and learning about the real-time scheduler. I thought I might share this story in case someone else finds themselves in a similar situation.

The basic issue was that PulseAudio daemon occasionally restarted. This reset some run-time configuration that should not be lost while the device was operating and also broke connections to clients that were talking to the daemon. Restarts were seemingly connected to the daemon or the CPU being under load. For example, the daemon would restart if many audio files were played simultaneously on it. I could reproduce the problem on PulseAudio 12.0 using a shell script similar to the following:

n=0
while [ $n -lt 100 ]; do pacmd play-file foo.wav 0 n=$(($n+1)) done  This triggers 100 playbacks of the foo.wav file at almost the same instant and would reliably make the daemon restart on the device. However I was sometimes seeing restarts with less than ten simultaneous audio plays. A similar script with 1000 plays would sometimes also cause a restart on my Intel-based laptop using the same PulseAudio version. This made it easier to investigate the problem since I didn't need to do the debugging remotely on the device. syslog held some clues what was happening. PulseAudio process was apparently being sent the SIGKILL signal. systemd detected that and restarted the service shortly after: systemd[1]: pulseaudio.service: Main process exited, code=killed, status=9/KILL systemd[1]: pulseaudio.service: Unit entered failed state. systemd[1]: pulseaudio.service: Failed with result 'signal'.  However, there were no other clues as to what sent the SIGKILL or why. Kernel log from dmesg had nothing whatsoever related to this. Increasing logging verbosity in systemd and PulseAudio showed nothing relevant. Attaching a debugger and strace to the PulseAudio process showed that the signal was received at seemingly random points in the execution of the daemon. This showed that the problem was not directly related to any specific line of code, but otherwise led me nowhere. When I searched the web, all suggestions seemed to point to the kernel killing the process due to an out-of-memory condition. The kernel being the cause of the signal seemed reasonable, however OOM condition is usually clearly logged. Another guess was that systemd itself was killing the process after I learned about its resource control feature. This turned out to be a dead end as well. The first real useful clue was when Gašper gave me a crash course on using perf. After setting up debugging symbols for the kernel and the PulseAudio binary, I used the following: $ perf_4.9 record -g -a -e 'signal:*'
(trigger the restart here)
$perf_4.9 script  This printed out a nice backtrace of the code that generated the problematic SIGKILL signal (among noise about uninteresting other signals being sent between processes on the system): alsa-sink-ALC32 12510 [001] 24535.773432: signal:signal_generate: sig=9 errno=0 code=128 comm=alsa-sink-ALC32 pid=12510 grp=1 res=0 7fffbae8982d __send_signal+0x80004520223d ([kernel.kallsyms]) 7fffbae8982d __send_signal+0x80004520223d ([kernel.kallsyms]) 7fffbaef0652 run_posix_cpu_timers+0x800045202522 ([kernel.kallsyms]) 7fffbaea7aa9 scheduler_tick+0x800045202079 ([kernel.kallsyms]) 7fffbaefaa80 tick_sched_timer+0x800045202000 ([kernel.kallsyms]) 7fffbaefa480 tick_sched_handle.isra.12+0x800045202020 ([kernel.kallsyms]) 7fffbaefaab8 tick_sched_timer+0x800045202038 ([kernel.kallsyms]) 7fffbaeebbfe __hrtimer_run_queues+0x8000452020de ([kernel.kallsyms]) 7fffbaeec2dc hrtimer_interrupt+0x80004520209c ([kernel.kallsyms]) 7fffbb41b1c7 smp_apic_timer_interrupt+0x800045202047 ([kernel.kallsyms]) 7fffbb419a66 __irqentry_text_start+0x800045202096 ([kernel.kallsyms])  alsa-sink-ALC32 is the thread in the PulseAudio daemon that is handling the interface between the daemon and the ALSA driver for the audio hardware. The stack trace shows that the signal was generated in the context of that thread, however the originating code was called from a timer interrupt, not a syscall. Specifically, the run_posix_cpu_timers function seemed to be the culprit. This was consistent with the random debugger results I saw before, since interrupts were not in sync with the code running in the thread. Some digging later I found the following code that is reached from run_posix_cpu_timers via some static functions. Intermediate static functions probably got optimized away by the compiler and don't appear in the perf stack trace: if (hard != RLIM_INFINITY && tsk->rt.timeout > DIV_ROUND_UP(hard, USEC_PER_SEC/HZ)) { /* * At the hard limit, we just die. * No need to calculate anything else now. */ __group_send_sig_info(SIGKILL, SEND_SIG_PRIV, tsk); return; }  Now things started to make sense. Linux kernel implements some limits on how much time a thread with real-time scheduling priority can use before cooperatively yielding the CPU to other threads and processes (via a blocking syscall for instance). If a thread hits this time limit it is silently sent the SIGKILL signal by the kernel. Kernel resource limits are documented in the setrlimit man page (the relevant limit here is RLIMIT_RTTIME). The PulseAudio daemon was setting the ALSA thread to real-time priority and it was getting killed under load. Using real-time scheduling seems to be the default in PulseAudio 12.0 and the time limit set for the process is 200 ms. The limit for a running daemon can be inspected from shell using prlimit: $ prlimit --pid PID | grep RTTIME
RTTIME     timeout for real-time tasks           200000    200000 microsecs


Details of real-time scheduling can be adjusted in /etc/pulse/daemon.conf, for instance with:

realtime-scheduling = yes
rlimit-rttime = 400000


Just to make sure that an RTTIME over-run indeed produces such symptoms I made the following C program that intentionally triggers it. Running the program showed that indeed the cause for the SIGKILL in this case isn't logged anywhere and produces a similar perf backtrace:

#include <stdio.h>
#include <sched.h>
#include <sys/resource.h>

int main(int argc, char** argv)
{
struct sched_param sched_param;
if (sched_getparam(0, &sched_param) < 0) {
printf("sched_getparam() failed\n");
return 1;
}
sched_param.sched_priority = sched_get_priority_max(SCHED_RR);
if (sched_setscheduler(0, SCHED_RR, &sched_param)) {
printf("sched_setscheduler() failed\n");
return 1;
}
printf("Scheduler set to Round Robin with priority %d...\n",
sched_param.sched_priority);
fflush(stdout);

struct rlimit rlimit;
rlimit.rlim_cur = 500000;
rlimit.rlim_max = rlimit.rlim_cur;

if (setrlimit(RLIMIT_RTTIME, &rlimit)) {
printf("setrlimit() failed\n");
return 1;
}
printf("RTTIME limit set to %ld us...\n",
rlimit.rlim_max);

printf("Hogging the CPU...\n");
while(1);
}


It would be really nice if kernel would log somewhere the reason for this signal, like it does with OOM. It might be that in this particular case developers wanted to avoid calling possibly expensive logging functions from interrupt context. On the other hand, it seems that kernel by default doesn't log any process kills at all due to resource limit over-runs. Failed syscalls can be logged using auditd, but that wouldn't help here as no syscalls actually failed.

As far as this particular PulseAudio application was concerned, there weren't really any perfect solutions. This didn't look like a bug in PulseAudio but rather a fact of life in a constrained environment with real-time tasks. The PulseAudio man page discusses some trade-offs of real-time scheduling (which is nice in hindsight, but you first have to know where to look). In my specific case, there were more or less only three possibilities of how to proceed:

1. Disable RTTIME limit and accept that PulseAudio might freeze other processes on the device for an arbitrary amount of time,
2. disable real-time scheduling and accept occasional skips in the audio due to other processes taking the CPU from PulseAudio for too long, or
3. accept the fact that PulseAudio will restart occasionally and make other software on the device recover from this case as best as possible.

After considering implications to the functionality of the device I went with the last one in the end. I also slightly increased the default RTTIME limit so that restarts would be less common while still having an acceptable maximum response time for other processes.

Posted by | Categories: Code | Comments »

## Analyzing PIN numbers

13.10.2018 12:17

Since I already had a dump from haveibeenpwned.com on my drive from my earlier password check, I thought I could use this opportunity to do some more analysis on it. Six years ago DataGenetics blog posted a detailed analysis of 4-digit numbers that were found in password lists from various data breaches. I thought it would be interesting to try to reproduce some of their work and see if their findings still hold after a few years and with a significantly larger dataset.

DataGenetics didn't specify the source of their data, except that it contained 3.4 million four-digit combinations. Guessing from the URL, their analysis was published in September 2012. I've done my analysis on the pwned-passwords-ordered-by-hash.txt file downloaded from haveibeenpwned.com on 6 October (inside the 7-Zip archive the file had a timestamp of 11 July 2018, 02:37:47). The file contains 517.238.891 SHA1 hashes with associated frequencies. By searching for SHA1 hashes that correspond to 4-digit numbers from 0000 to 9999, I found that all of them were present in the file. Total sum of their frequencies was 14.479.676 (see my previous post for the method I used to search the file). Hence my dataset was roughly 4 times the size of DataGenetics'.

Here are the top 20 most common numbers appearing in the dump, compared to the rank on the top 20 list from DataGenetics:

nnew nold PIN frequency
1 1 1234 8.6%
2 2 1111 1.7%
3 1342 1.1%
4 3 0000 1.0%
5 4 1212 0.5%
6 8 4444 0.4%
7 1986 0.4%
8 5 7777 0.4%
9 10 6969 0.4%
10 1989 0.4%
11 9 2222 0.3%
12 13 5555 0.3%
13 2004 0.3%
14 1984 0.2%
15 1987 0.2%
16 1985 0.2%
17 16 1313 0.2%
18 11 9999 0.2%
19 17 8888 0.2%
20 14 6666 0.2%

This list looks similar to the results published DataGenetics. The first two PINs are the same, but the distribution is a bit less skewed. In their results, first four most popular PINs accounted for 20% of all PINs, while here they only make up 12%. It seems also that numbers that look like years (1986, 1989, 2004, ...) have become more popular. In their list the only two in the top 20 list were 2000 and 2001.

DataGenetics found that number 2580 ranked highly in position 22. They concluded that this is an indicator that a lot of these PINs were originally devised on devices with numerical keyboards such as ATMs and phones (on those keyboards, 2580 is straight down the middle column of keys), even though the source of their data were compromised websites where users would more commonly use a 104-key keyboard. In the haveibeenpwned.com dataset, 2580 ranks at position 65, so slightly lower. It is still in top quarter by cumulative frequency.

Here are 20 least common numbers appearing in the dump, again compared to their rank on the bottom 20 list from DataGenetics:

nnew nold PIN frequency
9981 0743 0.00150%
9982 0847 0.00148%
9983 0894 0.00147%
9984 0756 0.00146%
9986 0934 0.00146%
9985 0638 0.00146%
9987 0967 0.00145%
9988 0761 0.00144%
9989 0840 0.00142%
9991 0835 0.00141%
9990 0736 0.00141%
9993 0742 0.00139%
9992 0639 0.00139%
9994 0939 0.00132%
9995 0739 0.00129%
9996 0849 0.00126%
9997 0938 0.00125%
9998 0837 0.00119%
9999 9995 0738 0.00108%
10000 0839 0.00077%

Not surprisingly, most numbers don't appear in both lists. Since these have the lowest frequencies it also means that the smallest changes will significantly alter the ordering. The least common number 8068 in DataGenetics' dump is here in place 9302, so still pretty much at the bottom. I guess not many people choose their PINs after the iconic Intel CPU.

Here is a grid plot of the distribution, drawn in the same way as in the DataGenetics' post. Vertical axis depicts the right two digits while the horizontal axis depicts the left two digits. The color shows the relative frequency in log scale (blue - least frequent, yellow - most frequent).

Many of the same patterns discussed in the DataGenetics' post are also visible here:

• The diagonal line shows popularity of PINs where left two and right two digits repeat (pattern like ABAB), with further symmetries superimposed on it (e.g. AAAA).

• The area in lower left corner shows numbers that can be interpreted as dates (vertically MMDD and horizontally DDMM). The resolution is good enough that you can actually see which months have 28, 30 or 31 days.

• The strong vertical line at 19 and 20 shows numbers that can be interpreted as years. The 2000s are more common in this dump. Not surprising, since we're further into the 21st century than when DataGenetics' analysis was done.

• Interestingly, there is a significant shortage of numbers that begin with 0, which can be seen as a dark vertical stripe on the left. A similar pattern can be seen in DataGenetics' dump although they don't comment on it. One possible explanation would be if some proportion of the dump had gone through a step that stripped leading zeros (such as a conversion from string to integer and back, maybe even an Excel table?).

In conclusion, the findings from DataGenetics' post still mostly seem to hold. Don't use 1234 for your PIN. Don't choose numbers that have symmetries in them or have years or dates in them. These all significantly increase the chances that someone will be able to guess them. And of course, don't re-use your SIM card or ATM PIN as a password on websites.

Another thing to note is that DataGenetics concluded that their analysis was possible because of leaks of clear-text passwords. However, PINs provide a very small search space of only 10000 possible combinations. It was trivial for me to perform this analysis even though haveibeenpwned.com dump only provides SHA-1 hashes, and not clear-text. With a warmed-up disk cache, the binary search only took around 30 seconds for all 10000 combinations.

Posted by | Categories: Life | Comments »