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.

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.

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

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

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

Homestudio migratie

Migratie voorloopt voorspoedig. Bijna alles draait weer en het systeem voelt weer lekker fris en fruitig aan. Enige echte lastpost is de real-time kernel die ik heb geïnstalleerd, die wil nog wel eens vastlopen (kernel panics). Maar dat komt waarschijnlijk omdat het al een oudere versie is (zo te zien 3.2.14-rt24, recentste versie is 3.2.19-rt30). Zal dus de lowlatency kernel moeten gebruiken, nog niet uitgebreid getest maar ik denk dat dat wel goed komt. Dan kan ik ook zonder problemen de plug-ins gebruiken van het Distrho project. Die maken bijna allemaal gebuik van het Juce framework en dat framework is voor zover ik het heb begrepen niet helemaal real-time safe zoals dat heet. Oftewel, plug-ins gebaseerd op dat framework doen het niet goed met een real-time kernel en kunnen zelfs je systeem laten crashen.

Homestudio migratie

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

Frisse start

Eindelijk mijn muziek PC gemigreerd naar Ubuntu 10.04 Lucid Lynx. Van de week is mijn nieuwe geluidskaart binnengekomen (een Focusrite Saffire Pro 40) en Jof van Tango Studio schoot me aan op IRC met de vraag of ik zijn real-time 2.6.33 kernel wilde proberen. Twee goeie redenen om te switchen. Ten eerste omdat ik de Saffire Pro 40 al uitgebreid heb kunnen testen onder 10.04 met mijn eigen FFADO pakketjes en ten tweede omdat ik met de kernel van Tango Studio de beschikking heb over de nouveau drivers voor mijn Nvidia kaart. Ben nu dus niet meer afhankelijk van die closed source drivers van Nvidia die de laatste tijd nogal wat problemen schijnen te geven in combinatie met recentere real-time kernels. Ook heb ik nu geen last meer van de devtmpfs bug die toch niet opgelost gaat worden aangezien de maintainer van de Ubuntu real-time kernel er mee gaat stoppen.

Had nog wel een raar probleempje met JACK. Kreeg iedere keer als ik bijv. Yoshimi of PHASEX opstartte de volgende melding:

ports used in attemped connection are not of the same data type

Dacht eerst dat het misschien aan JACK lag maar na op de LAU mailinglist gevraagd te hebben wat deze melding nou precies betekende had ik al snel een vermoeden dat het waarschijnlijk aan a2jmidid lag. De Saffire Pro 40 doet er namelijk een stuk langer over om op te komen dan de Pro 10 van de band. En met de Pro 10 werkt mijn a2jmidid opstartscriptje wel goed maar met de Pro 40 start a2jmidid op voordat de audio poorten opkomen. Dit heeft als gevolg dat veel applicaties die met de eerst twee beschikbare audio JACK input poorten willen verbinden (normaliter dus ook audio poorten) nu aan de a2jmidid JACK MIDI poorten worden geknoopt (dat zijn immers de als eerste aangemaakte input poorten). Oftewel, de applicatie probeert audio poorten met MIDI poorten te verbinden en vandaar de melding. Mijn opstartscriptje voor a2jmidid ziet er nu als volgt uit:


while [ "$JACK_TEST" != "system" ]
JACK_TEST=$(jack_lsp 2>/dev/null | grep -m1 -e "system" | cut -d ":" -f 1)
sleep 2

a2jmidid -e &


Werkt weer prima. Kan nog beter uiteraard want QjackCtl blijft nu hangen zo lang de while loop actief is, maar daar vind ik nog wel een elegantere oplossing voor.

Frisse start