Working on a stable setup

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:

dwc_otg.lpm_enable=0 dwc_otg.speed=1 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootflags=data=writeback elevator=deadline rootwait

Setting USB speed to Full Speed (so USB1.1) by using dwc_otg.speed=1 is necessary otherwise the audio coming out of my USB DAC sounds distorted.

I’m starting ZynAddSubFX as follows:

zynaddsubfx -r 48000 -b 64 -I alsa -O alsa -P 7777 -L /usr/share/zynaddsubfx/banks/SynthPiano/0040-BinaryPiano2.xiz

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.

Working on a stable setup

Building a synth module using a Raspberry Pi

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.

zynaddsubfx-ext-guiBut 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:

options snd-usb-audio index=0,1 vid=0x08bb,0x09e8 pid=0x2704,0x007c

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:

zynaddsubfx -r 48000 -b 256 -I alsa -O alsa -P 7777

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://

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.

Building a synth module using a Raspberry Pi

Raspberry Pi Revisited

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. 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.

I’d love to get Guitarix running on the RPi2 with the Cirrus Logic Audio Card so that will be the next challenge.

Raspberry Pi Revisited

Raspberry Jam Review

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‘s presentation. 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.


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!

Raspberry Jam Review

Exit BeagleBone Black, hello Cubieboard2!

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.

text-align: center;


RT patchset 3.4.61-rt77 for linux-sunxi, sunxi-3.4 branch

Low latency defaults patch for sunxi-codec driver

Exit BeagleBone Black, hello Cubieboard2!

First Dutch Raspberry Jam

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

Ordina Raspberry Jam

Raspberry Pi Playlist @ AutoStatic’s YouTube channel

First Dutch Raspberry Jam

More ARM goodies II

Received the BeagleBone Black (BBB) and the MK808 with a RK3066 SoC. My first impressions are really positive. Especially the BBB is quite an awesome device that I’m probably going to use a lot in favor of the Raspberry Pi. At first glance I had something like, the BBB blows the RPi away, but as soon as I started looking for documentation on how to put Debian on it for instance it became clear that the RPi is still the device to beat. The RPi community is huge, documentation for it is well laid out and working with the RPi is just so easy. The BBB on the other hand lacks a vivid community, is $10 more expensive and a lot more difficult to work with. Take the Debian install for example, seems quite some work to get that going.

The MK808 is surely an improvement over the UG80X I already own. It comes with a HDMI port instead of a HDMI plug, has an extra USB OTG port, a heatsink, hardware serial console access, a reset button and a power indicator LED. The pre-installed Android version looks better too. I flashed my RT kernel recovery image on it, inserted the Micro SD from my UG80X and it booted without any issues. So I’m going to pursue my goal to get a real-time, low-latency environment running on a RK3066 based device on the MK808 and find another purpose for the UG80X.

Edit: Getting Debian to work on the BBB is actually quite easy:
Next time I’ll promise to make better use of my Google skills.

More ARM goodies II

Hacking an Android TV stick, the sequel

jeremy@rk3066:~$ uname -a
Linux rk3066 3.0.36-rt58 #1 SMP PREEMPT RT Thu Jul 4 13:18:23 CEST
2013 armv7l GNU/Linux

Managed to compile and run a real-time kernel on the Android TV stick with the RK3066 SoC. Packaged the latest version of amSynth (1.4.0 which has been released recently), installed it, fired up JACK and amSynth and so far no xruns, nothing. And this is with -p64!

jackd -P84 -p32 -t2000 -dalsa -dhw:Device -n3 -p64 -r44100 -s -P

I should measure the latency of the $2 USB audio interface I’m using to find out what the total latency of this set-up is. Well, at least I got the system latency for usage with softsynths like amSynth down to 64/44100*2=3ms. Now that’s a usable situation.

jeremy@rk3066:~$ lsusb | grep -i c-media
Bus 002 Device 006: ID 0d8c:000e C-Media Electronics, Inc. Audio Adapter (Planet
UP-100, Genius G-Talk)
jeremy@rk3066:~$ cat /proc/asound/cards 0 [RK29RK1000 ]: RK29_RK1000 - RK29_RK1000 RK29_RK1000 1 [HDMI ]: ROCKCHIP_HDMI - ROCKCHIP HDMI ROCKCHIP HDMI 2 [Device ]: USB-Audio - Generic USB Audio Device Generic USB Audio Device at usb-usb20_host-1.1, full speed

A big pro of this stick is that it suffers less from SD card corruption than my RPi. Yesterday evening I wrecked up yet another SD card when testing my RPi with a real-time kernel, it’s getting a bit cumbersome. Speaking of real-time kernels, it was quite some work to apply the RT patchset to the RockChip kernel source. Had to add stuff by hand and when I finally got everything in place it wouldn’t compile. But I managed to solve all the build errors. After flashing the kernel image the TV stick wouldn’t boot of course, it hung at some point. But I quickly saw that the issue was with the SD card reader and that it was similar to the SD card reader issue on the RPi for which I found a workaround. So I added an #ifdef clause to the RockChip SD card reader driver, recompiled, reflashed and wham, it continued booting. Now I have to clean up my build directory and get a usable diff of it against the pristine RK3066 kernel sources.

Hacking an Android TV stick, the sequel

Zelf een real-time kernel bouwen voor Ubuntu 12.04

De real-time kernel uit de PPA van Alessio Bogani liep bij mij nog wel eens vast dus heb ik er zelf een gebouwd met de meest recente 3.2 kernel en bijbehorende RT patchset. En dit draait een stuk stabieler, nog geen lockups gehad.

Een eigen kernel bouwen is gelukkig nog steeds niet zo heel moeilijk, met Ubuntu kun je zelfs heel gemakkelijk pakketten maken met behulp van de make-kpkg utility. Na wat googlen kwam ik onderstaande handleiding tegen en simpeler kan het bijna niet.

Installeer de benodigde pakketten:

sudo apt-get install kernel-package fakeroot build-essential libncurses5-dev

Download de kernel sources en de RT patchset:

mkdir -p ~/tmp/linux-rt
cd ~/tmp/linux-rt
wget -c
wget -c

Pak de kernel sources uit en patch deze met de RT patchset:

tar xjvf linux-3.2.28.tar.bz2
cd linux-3.2.28
patch -p1 < <(bunzip2 -c ../patch-3.2.28-rt42.patch.bz2)

Nu moet je de kernel nog configureren. De gemakkelijkste manier is om een bestaande kernel config te nemen, deze staan in de /boot directory van je systeem. Kopieer een config naar je werkdirectory en gebruik deze als uitgangspunt:

cp /boot/config-$(uname -r) .config

Dit commando kopieert de kernel config van de kernel die je op dat moment gebruikt. Je kunt ook de config van een andere kernel gebruiken, bijv. die van de Ubuntu lowlatency kernel aangezien deze al geoptimaliseerd is voor Linux audio toepassingen. De volgende stap is om een kernel config aan te maken met full preemption ingeschakeld aan de hand van de gekopieerde kernel config:

make oldconfig

Je kunt alle prompts wegklikken met Enter, behalve de prompt welk Preemption Model je wilt gebruiken. Selecteer daar 5 (Fully Preemtible Kernel):

Preemption Model
> 1. No Forced Preemption (Server) (PREEMPT_NONE)
  2. Voluntary Kernel Preemption (Desktop) (PREEMPT_VOLUNTARY)
  3. Preemptible Kernel (Low-Latency Desktop) (PREEMPT__LL) (NEW)
  4. Preemptible Kernel (Basic RT) (PREEMPT_RTB) (NEW)
  5. Fully Preemptible Kernel (RT) (PREEMPT_RT_FULL) (NEW)
choice[1-5]: 5 <Enter>

Workaround voor

sed -rie 's/echo "+"/#echo "+"/' scripts/setlocalversion

Nu kun je de kernel gaan bouwen:

make-kpkg clean
CONCURRENCY_LEVEL=$(getconf _NPROCESSORS_ONLN) fakeroot make-kpkg
--initrd --revision=0 kernel_image kernel_headers

Als het bouwen klaar is (kan een tijd duren) kun je de kernel pakketjes installeren:

cd ..
sudo dpkg -i linux-{headers,image}-3.2.28-rt42_0_*.deb

Rebooten, nieuwe real-time kernel selecteren in je bootloader (GRUB) en je systeem zou nu moeten booten met de net gebouwde real-time kernel.

Zelf een real-time kernel bouwen voor Ubuntu 12.04