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

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!

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

LinuxMusicians Wiki update

Ben de System Configuration pagina van de LinuxMusician Wiki wat aan het bijwerken. Paragraaf toegevoegd over rtirq en het gebruik van het setpci commando voor het instellen van de latency van PCI devices. Verder wat spul geüpdate en wat dode links aangepast of verwijderd. En wat aandacht besteed aan de nieuwe RT patchset voor de 3.0 kernel en de threadirqs boot optie voor kernels >= 2.6.39.

LinuxMusicians Wiki update

Realtime patchset zo goed als stabiel?

Het ziet er naar uit dat de realtime patchset voor de 3.0 kernel zo’n beetje uitontwikkeld is. Gisteren is 3.0.8-rt22 gereleased en het aantal fixes is minimaal. Ook geeft de hoofdontwikkelaar aan verder te willen gaan met 3.2 zodra de 3.0 patchset echt goed stabiel is. Binnenkort zelf maar eens een 3.0 realtime kernel brouwen voor mijn Oneiric installatie. Ja, heb 11.10 geïnstalleerd op m’n notebook en ook al is Unity waarschijnlijk niet echt bruikbaar voor een Linux audio systeem was mijn eerste indruk positief (en mijn meissie was helemaal enthousiast, die wilde gelijk ook zo’n zijbalk). Op m’n nieuwe werkplek heb ik het inmiddels ook geïnstalleerd, tenminste, heb na een minimale install het lubuntu-desktop pakket erop gezet. Heb een paar keer naar AVLinux gekeken en vond dat er erg goed en werkbaar uitzien dus draai nu ook een LXDE desktop op het werk en vooralsnog bevalt het prima.

Realtime patchset zo goed als stabiel?

Nieuwe release RT patchset

Ook al zijn forced threaded interrupt handlers inmiddels onderdeel van de mainline kernel (vanaf 2.6.39), neemt niet weg dat er nog het nodige verbeterd kan worden aan de real-time performance van recentere kernels. Thomas Gleixner en co. hebben de aankomende release van de 3.0 kernel aangegrepen om met een nieuwe release van hun real-time patchset te komen. 3.0-rc7-rt0 is inmiddels beschikbaar en de eerste reacties zijn postief.

Nieuwe release RT patchset