A new version of rtcqs, a Linux audio performance analyzer, is now available. Most notable changes include:
Fixed inconsistent use of single and double quotes
Replaced audio group check with a group agnostic check (fixes #4)
Governor check can now deal with systems that have SMT disabled
Tickless check now deals with all CONFIG_NO_HZ* variants and with nohz being set on the kernel command line (fixes #8)
File systems check has been expanded
IRQ check now loops through /sys/kernel/irq instead of parsing /proc/interrupts
rtprio check now checks if a SCHED_FIFO priority can be set instead of a SCHED_RR priority
Improved preempt RT check, check if “preempt=full” is part of the kernel command line (fixes #7)
Refactoring, created separate classes for main app, resources and GUI
Moved all packaging directives into pyprojects.toml
While working on this release I found out PySimpleGUI is not open source anymore so rtcqs’ GUI has become a bit of a moving target. I’m looking at alternatives like pygubu or even popsicle but that will be something for in the long run. In the short run there are more improvements in the pipeline. The swappiness check needs some attention and same goes for the IRQ check. I’ve been working on a different project to automate prioritizing IRQs and I’m planning to to reuse some parts of that project for the IRQ check in rtcqs. The idea is to have rtcqs not only list the status of all audio related IRQs but also any audio devices attached to those IRQs.
rtcqs is available on Codeberg, PyPI and is also included in the AUR.
This release comes with a new Power Management check which checks if the audio group has read/write permissions on /dev/cpu_dma_latency. If your user is a member of the audio group and permissions are set for this group then DAW’s like Ardour and Reaper can open this file as your user, keep it open and control power management this way. This allows a user to prevent CPU sleep states for example so your CPUs are always on and instantly available which could lower the chance running into xruns.
This release also introduces a new basic and simple tkinter-based GUI. The Qt GUI does look fancy but to use it it also needs a fancy amount of dependencies. When building binaries with PyInstaller the result of the Qt GUI is a whopping 130MB package while the tkinter version stays below 12MB.
Future plans are to get rid of some checks:
Max user watches as it’s not related to the overall performance of your system
System timer as it’s not relevant anymore, rtcqs already checks for the more relevant stuff (high res timers and tickless kernel)
Background processes as it’s merely a placeholder which checks for two processes that don’t exist anymore on modern systems
I’m having my doubts about swappiness too as it’s not really applicable anymore for modern machines. But I’m curious if it still applies for smaller systems like RPi’s for example. I’d like to add a filesystem mount option check, for Ext it would check if the filesystem is mounted at least with the relatime option or even noatime for example. And maybe a disk scheduler check but I’m not conviced yet that it really makes a difference.
rtcqs v0.3.1 is now available on Codeberg and Github. rtcqs is the continuation of the realtimeconfigquickscan project but then rewritten in Python. It comes with a Qt GUI and a few extra checks.
Dear all,
I’d like to announce rtcqs, the continuation of the realtimeconfigquickscan project. It’s a port to Python with some added extra’s, like a Spectre/Meltdown mitigations check and a Qt GUI. It has the approval of the original author of realtimeconfigquickscan to whom I owe a debt of gratitude, not only for the original code but also for his helpfulness with the continuation, or maybe even evolution of the project.
So check it out, indulge me with bugs, issues, improvements or any other useful feedback on the Codeberg repo which you can find at at https://codeberg.org/rtcqs/rtcqs
Happy system tuning and happy holidays!
Jeremy
While setting up a solution to fully automate the deployment of SSL certificates at work I piggybacked on the flow and focus to rewrite the realtimeconfigquickscan Perl code in Python. As part of the certificate deployment project I wrote an application to decrypt, re-encrypt and base64 encode PFX files so they can be uploaded to a vault solution. This way I ran into PySimpleGUI which enabled me to quickly put together a nice looking Qt GUI.
rtcqs main window
The code could be more terse and probably contains some typical non-programmer idiosyncracies. First improvement will be to make the code more dynamic so the GUI gets generated instead of using hardcoded values like it does now. And I’d like to add a power management check but then I first need to read up on that subject. There are also some checks that might need some more scrutiny like the swappiness and max_user_watches checks to verify if those checks are really needed for a real-time audio environment.
As a beta tester for MOD I thought it would be cool to play around with netJACK which is supported on the MOD Duo. The MOD Duo can run as a JACK master and you can connect any JACK slave to it as long as it runs a recent version of JACK2. This opens a plethora of possibilities of course. I’m thinking about building a kind of sidecar device to offload some stuff to using netJACK, think of synths like ZynAddSubFX or other CPU greedy plugins like fat1.lv2. But more on that in a later blog post.
So first I need to set up a sidecar device and I sacrificed one of my RPi’s for that, an RPi 3. Flashed an SD card with Raspbian Jessie Lite and started to do some research on the status of real time kernels and the Raspberry Pi because I’d like to use a real time kernel to get sub 5ms system latency. I compiled real time kernels for the RPi before but you had to jump through some hoops to get those running so I hoped things would have improved somewhat. Well, that’s not the case so after having compiled a first real time kernel the RPi froze as soon as I tried to runapt-get install rt-tests. After having applied a patch to fix how the RPi folks implemented the FIQ system the kernel compiled without issues:
Linux raspberrypi 4.9.33-rt23-v7+ #2 SMP PREEMPT RT Sun Jun 25 09:45:58 CEST 2017 armv7l GNU/Linux
And the RPi seems to run stable with acceptable latencies:
So that’s a maximum latency of 75 µs, not bad. I also spotted some higher values around 100 but that’s still okay for this project. The histogram was created with mklatencyplot.bash. I used a different invocation of cyclictest though:
cyclictest -Sm -p 80 -n -i 500 -l 300000
And I ran hackbench in the background to create some load on the RPi:
(while true; do hackbench > /dev/null; done) &
Compiling a real time kernel for the RPi is still not a trivial thing to do and it doesn’t help that the few howto’s on the interwebs are mostly copy-paste work, incomplete and contain routines that are unclear or even unnecessary. One thing that struck me too is that the howto’s about building kernels for RPi’s running Raspbian don’t mention the make deb-pkg routine to build a real time kernel. This will create deb packages that are just so much easier to transfer and install then rsync’ing the kernel image and modules. Let’s break down how I built a real time kernel for the RPi 3.
First you’ll need to git clone the Raspberry Pi kernel repository:
This will only clone the rpi-4.9.y branch into a directory called linux without any history so you’re not pulling in hundreds of megs of data. You will also need to clone the tools repository which contains the compiler we need to build a kernel for the Raspberry Pi:
The KERNEL variable is needed to create the initial kernel config. The ARCH variable is to indicate which architecture should be used. The CROSS_COMPILE variable indicates where the compiler can be found. The CONCURRENCY_LEVEL variable is set to the number of cores to speed up certain make routines like cleaning up or installing the modules (not the number of jobs, that is done with the -j option of make).
Now that the environment variables are set we can create the initial kernel config:
cd linux
make bcm2709_defconfig
This will create a .config inside the linux directory that holds the initial kernel configuration. Now download the real time patch set and apply it:
cd ..
wget https://www.kernel.org/pub/linux/kernel/projects/rt/4.9/patch-4.9.33-rt23.patch.xz
cd linux
xzcat ../patch-4.9.33-rt23.patch.xz | patch -p1
Most howto’s now continue with building the kernel but that will result in a kernel that will freeze your RPi because of the FIQ system implementation that causes lock ups of the RPi when using threaded interrupts which is the case with real time kernels. That part needs to be patched so download the patch and dry-run it:
cd ..
wget https://www.osadl.org/monitoring/patches/rbs3s/usb-dwc_otg-fix-system-lockup-when-interrupts-are-threaded.patch
cd linux
patch -i ../usb-dwc_otg-fix-system-lockup-when-interrupts-are-threaded.patch -p1 --dry-run
You will notice one hunk will fail, you will have to add that stanza manually so note which hunk it is for which file and at which line it should be added. Now apply the patch:
And add the failed hunk manually with your favorite editor. With the FIQ patch in place we’re almost set for compiling the kernel but before we can move on to that step we need to modify the kernel configuration to enable the real time patch set. I prefer doing that with make menuconfig. You will need the libncurses5-dev package to run this commando so install that with apt-get install libncurses5-dev. Then select Kernel Features - Preemption Model - Fully Preemptible Kernel (RT) and select Exit twice. If you’re asked if you want to save your config then confirm. In the Kernel features menu you could also set the the timer frequency to 1000 Hz if you wish, apparently this could improve USB throughput on the RPi (unconfirmed, needs reference). For real time audio and MIDI this setting is irrelevant nowadays though as almost all audio and MIDI applications use the hr-timer module which has a way higher resolution.
With our configuration saved we can start compiling. Clean up first, then disable some debugging options which could cause some overhead, compile the kernel and finally create ready to install deb packages:
make clean
scripts/config --disable DEBUG_INFO
make -j$(nproc) deb-pkg
Sit back, enjoy a cuppa and when building has finished without errors deb packages should be created in the directory above the linux one. Copy the deb packages to your RPi and install them on the RPi with dpkg -i. Open up /boot/config.txt and add the following line to it:
kernel=vmlinuz-4.9.33-rt23-v7+
Now reboot your RPi and it should boot with the realtime kernel. You can check with uname -a:
Linux raspberrypi 4.9.33-rt23-v7+ #2 SMP PREEMPT RT Sun Jun 25 09:45:58 CEST 2017 armv7l GNU/Linux
Since Rasbian uses almost the same kernel source as the one we just built it is not necessary to copy any dtb files. Also running mkknlimg is not necessary anymore, the RPi boot process can handle vmlinuz files just fine.
The basis of the sidecar unit is now done. Next up is tweaking the OS and setting up netJACK.
Edit: there’s a thread on LinuxMusicians referring to this article which already contains some very useful additional information.
Next step for the synth module project was to get the Raspberry Pi 2 to run in a stable manner. It seems like I’m getting close or that I’m already there. First I built a new RT kernel based on the 4.1.7 release of the RPi kernel. Therefore I had to checkout an older git commit because the RPi kernel is already at 4.1.8. The 4.1.7-rt8 patchset applied cleanly and the kernel booted right away:
pi@rpi-jessie:~$ uname -a
Linux rpi-jessie 4.1.7-rt8-v7 #1 SMP PREEMPT RT Sun Sep 27 19:41:20 CEST 2015 armv7l GNU/Linux
After cleaning up my cmdline.txt it seems to run fine without any hiccups so far. My cmdline.txt now looks like this:
With a buffer of 64 frames latency is very low and so far I haven’t run into instruments that cause a lot of xruns with this buffer size. Not even the multi-layered ones from Will Godfrey.
So I guess it’s time for the next step, creating a systemd startup unit so that ZynAddSubFX starts at boot. And it would be nice if USB MIDI devices would get connected automatically. And if you could see somehow which instrument is loaded, an LCD display would be great for this. Also I’d like to have the state of the synth saved, maybe by saving an .xmz file whenever there’s a state change or on regular intervals. And the synth module will need a housing or casing. Well, let’s get the software stuff down first.
Ever since I did an acid set with my brother in law at the now closed bar De Vinger I’ve been playing with the idea of creating some kind of synth module out of a Raspberry Pi. The Raspberry Pi 2 should be powerful enough to run a complex synth like ZynAddSubFX. When version 2.5.1 of that synth got released the idea resurfaced again since that version allows to remote control a running headless instance of ZynAddSubFX via OSC that is running on for instance a Raspberry Pi. I looked at this functionality before a few months ago but the developer was just starting to implement this feature so it wasn’t very usable yet.
But with the release of ZynAddSubFX 2.5.1 the stabilitity of the zynaddsubfx-ext-gui utility has improved to such an extent that it’s a very usable tool. In the above screenshot you can see zynaddsubfx-ext-gui running on my notebook with Ubuntu 14.04 controlling a remote instance of ZynAddSubFX running on a Raspberry Pi.
So basically all the necessary building blocks for a synth module are there. Coupled with my battered Akai MPK Mini and a cheap PCM2704 USB DAC I started setting up a test setup.
For the OS on the Raspberry Pi 2 I chose Debian Jessie as I feel Raspbian isn’t getting you the most out of your Pi. It’s running a 4.1.6 kernel with the 4.1.5-rt5 RT patch set, which applied cleanly and seems to run so far:
pi@rpi-jessie:~$ uname -a
Linux rpi-jessie 4.1.6-rt0-v7 #1 SMP PREEMPT RT Sun Sep 13 21:01:19 CEST 2015 armv7l GNU/Linux
This isn’t a very clean solution of course so let’s hope a real 4.1.6 RT patch set will happen or maybe I could give the 4.1.6 PREEMPT kernel that rpi-update installed a try. I packaged a headless ZynAddSubFX for the RPi on my notebook using pbuilder with a Jessie armhf root and installed the package for Ubuntu 14.04 from the KXStudio repos. I slightly overclocked the RPi to 1000MHz and set the CPU scaling governor to performance. The filesystem is Ext4, mounted with noatime,nobarrier,data=writeback.
To get the USB audio interface and the USB MIDI keyboard into line I had to add the following line to my /etc/modprobe.d/alsa.conf file:
This makes sure the DAC gets loaded as the first audio interface, so with index 0. Before adding this line the Akai would claim index 0 and since I’m using ZynAddSubFX with ALSA it couldn’t find an audio interface. But all is fine now:
pi@rpi-jessie:~$ cat /proc/asound/cards
0 [DAC ]: USB-Audio - USB Audio DAC
Burr-Brown from TI USB Audio DAC at usb-bcm2708_usb-1.3, full speed
1 [mini ]: USB-Audio - MPK mini
AKAI PROFESSIONAL,LP MPK mini at usb-bcm2708_usb-1.5, full speed
So no JACK as the audio back-end, the output is going directly to ALSA. I’ve decided to do it this way because I will only be running one single application that uses the audio interface so basically I don’t need JACK. And JACK tends to add a bit of overhead, you barely notice this on a PC system but on small systems like the Raspberry Pi JACK can consume a noticeable amount of resources. To make ZynAddSubFX use ALSA as the back-end I’m starting it with the -O alsa option:
The -r option sets the sample rate, the -b option sets the buffer size, -I is for the MIDI input and the -P option sets the UDP port on which ZynAddSubFX starts listening for OSC messages. And now that’s the cool part. If you then start zynaddsubfx-ext-gui on another machine on the network and tell it to connect to this port it starts only the GUI and sends all changes to the GUI as OSC messages to the headless instance it is connected to:
zynaddsubfx-ext-gui osc.udp://10.42.0.83:7777
Next up is stabilizing this setup and testing with other kernels or kernel configs as the kernel I’ve cooked up now isn’t a viable long-term solution. And I’d like to add a physical MIDI in and maybe a display like described on the Samplerbox site. And the project needs a casing of course.
When the Raspberry Pi 2 was released I certainly got curious. Would it be really better than it’s little brother? As soon as it got available in The Netherlands I bought it and sure this thing flies compared to the Raspberry Pi 1. The four cores and 1GB of memory are certainly an improvement. The biggest improvement though is the shift from ARMv6 to ARMv7. Now you can really run basically anything on it and thus I soon parted from Raspbian and I’m now running plain Debian Jessie armhf on the RPi.
So is everything fine and dandy with the RPi2? Well, no. It still uses the poor USB implementation and audio output. And it was quite a challenge to prepare it for its intended use: a musical instrument. To my great surprise a new version of the Wolfson Audio Card was available too for the new Raspberry Pi board layout so as soon as people reported they got it to work with the RPi2 I ordered one too.
Cirrus Logic Audio Card for Raspberry Pi
One of the first steps to make the device suitable for use as a musical device was to build a real-time kernel for it. Building the kernel itself was quite easy as the RT patchset of the kernel being used at the moment by the Raspberry Foundation (3.18) applied cleanly and it also booted without issues. But after a few minutes the RPi2 would lock up without logging anything. Fortunately there were people on the same boat as me and with the help of the info and patches provided by the Emlid community I managed to get my RPi2 stable with a RT kernel.
Next step was to get the right software running so I dusted off my RPi repositories and added a Jessie armhf repo. With the help of fundamental the latest version of ZynAddSubFX now runs like charm with very acceptable latencies, when using not all too elaborate instrument patches Zyn is happy with an internal latency of 64/48000=1.3ms. I haven’t measured the total round-trip latency but it probably stays well below 10ms. LinuxSampler with the Salamander Grand Piano sample pack also performs a lot better than on the RPi1 and when using ALSA directly I barely get any underruns with a slightly higher buffer setting.
Last Thursday the first Dutch Raspberry Jam took place at the Ordina HQ in Nieuwegein. I offered to do a presentation slash demonstration about realtime audio and the the Raspberry Pi so I promised myself to be there at least an hour before the scheduled starting time of my demo. That way I could also join Gert van Loo‘spresentation. When I arrived at 19:15 there was no Gert van Loo though so that should’ve triggered some alarms. Also I didn’t look out for members of the organization as soon as I came in. Instead I chose to dot the i’s and cross the t’s with regards to my demo.
Wrong decision.
About half an hour later the event was closed.
WTF?
I approached the person who closed the event and introduced myself. He replied that they thought I wasn’t coming anymore. Apparently they misinterpreted my e-mail I sent earlier that day that I didn’t manage to produce something workable for the laser show guy. They took it for a cancellation. But immediately the event got kind of reopened and I set up my stuff. We had some audio issues but in the end everything went quite well actually. I showed off what is possible with a Raspberry Pi and realtime audio with the use of some of my favorite software. Guitarix featured of course. I grabbed my guitar, fired up guitarix on the RPi and played some stuff. Hooked up my MIDI foot controller and showed how to select different presets. I also demonstrated the use of the RPi as a piano with the help of LinuxSampler and the awesome Salamander Grand Piano samplepack and did some drumming by using drumkv1. Before the realtime audio demo I presented an overview of the Linux audio ecosystem and talked about the alternatives of how to get sound in and out of your Raspberry Pi. These alternatives are not bound to the onboard sound and USB, since recently it is also possible to hook up an external audio codec to the I2S bus of the Raspberry Pi. I got one in myself this week, a MikroElektronika Audio Codec PROTO board based on the WM8731 codec, so more on that soon. It’d be awesome if I can get that codec to work reliably at lower latencies.
So it all turned out well, I had a great time doing my presentation and judging by the interest shown by some attendants who came up to me after the presentation I hope I got some more people enthusiastic about doing realtime audio with the Raspberry Pi and Linux. So thanks Ordina for offering this opportunity and thanks everyone who stuck around!
Put up my BeagleBone Black for sale. It was gathering dust, somehow this board doesn’t appeal to me. Biggest drawback is that it seems to be very picky with power adapters. If you don’t use a linear power adapter USB devices might not work properly. And that was exactly the issue I was facing, I just couldn’t get my USB audio interfaces to work on the BBB. So I lost interest because well, that’s what I bought the device for, to get sound out of it with the help of an USB audio interface. Add to this that there is no realtime kernel or RT patchset available for the BBB and that the BBB is quite a complex little device (it’s actually a REAL dev board). It would’ve cost me too much time to completely fathom it. No bad feelings though, the BBB is a very nice product and it sure has the slickest looks of all ARM SoC dev boards around.
Also I got a Cubieboard2 in recently. And that board has absorbed me for the last week and a half. It’s quite easy to set up (not as easy as the RPi though), has a lot of IO (yes, it has audio in and out!) and it blows both the RPi and BBB away when it comes to performance with its dual core A20 Allwinner SoC that can easily be overclocked to 1.2 GHz. Alas, no realtime kernel or RT patchset either but hey, I managed to get a RT kernel running on a Rockchip RK3066 based device so I could at least give it a try. And it worked out well. I’m now running a 3.4.61-rt77 kernel on it with a custom Debian Wheezy installation. This time I used git to keep track of the modifications I made so it was a lot easier to create a usable diff. I also patched the driver for the onboard audio codec because the hardcoded defaults were just unusable for realtime audio. Minimum number of periods was 4 and minimum buffer size was 1024. Don’t ask me why. So I’ve changed these to 2 and 16 respectively and managed to get JACK running at a respectable -p64 -n2 -r44100. Fired up some JACK clients and this little monster keeps up very well. USB audio interfaces are no problem either, I can run my Edirol UA25 in Advanced mode with -p64 -n3 -r48000 without any hitch. This is probably because the Cubieboard2 doesn’t use a Synopsys DesignWare OTG controller with out-of-tree dwc_otg drivers like the RPi but a better supported USB controller. At the moment the Cubieboard2 is the nicest ARM dev board I have laid my hands on so far.
The first Dutch Raspberry Jam will take place on Thursday September 26 at the Ordina HQ in Nieuwegein. I’ve offered to do a presentation about doing real-time audio with the Raspberry Pi which has been accepted. Internet visibility of this event is minimal at the moment though, let’s hope it caches on.
So expect a presentation/demo about using your Raspberry Pi as a sequencer, synthesizer, sampler or virtual guitar amp. I will show how to configure, tweak and tune your RPi for real-time, low-latency audio and what the possibilities of such a set-up are. I’ll probably do a live demo too of some tracks generated by one or more RPi’s