RPi 3 and the real time kernel

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:

Histogram of the latency on the RPi with a real time kernel during 300000 cyclictest loops
Histogram of the latency on the RPi with a real time kernel during 300000 cyclictest loops

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:

git clone -b 'rpi-4.9.y' --depth 1 https://github.com/raspberrypi/linux.git

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:

git clone https://github.com/raspberrypi/tools.git

This will end up in the tools directory. Next step is setting some environment variables so subsequent make commands pick those up:

export KERNEL=kernel7
export ARCH=arm
export CROSS_COMPILE=/path/to/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-
export CONCURRENCY_LEVEL=$(nproc)

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:

patch -i ../usb-dwc_otg-fix-system-lockup-when-interrupts-are-threaded.patch -p1

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.

RPi 3 and the real time kernel

Wolfson Audio Card for Raspberry Pi

Just ordered a Wolfson Audio Card for Raspberry Pi via RaspberryStore. I asked them about this audio interface at their stand during the NLLGG meeting where I did a presentation about doing real-time audio with the RPi and they told me they would ship it as soon as it would become available. They kept their word so I’m hoping to mount this buddy on my RPi this very week. Hopefully it will be an improvement and allow me to achieve low latencies with a more stable RPi so that I can use it in more critical environments (think live on stage). It has a mic in so I can probably set up the RPi with the Wolfson card quite easily as a guitar pedal. Just a pot after the line output, stick it in a Hammond case, put guitarix on it and rock on.

Wolfson Audio Card for Raspberry Pi
Wolfson Audio Card for Raspberry Pi

Wolfson Audio Card for Raspberry Pi

Using a Raspberry Pi as a piano

Recently I posted about my successful attempt to get LinuxSampler running on the Raspberry Pi. I’ve taken this a bit further and produced a script that turns the Raspberry Pi into a fully fledged piano. Don’t expect miracles, the sample library I used is good quality so the RPi might choke on it every now and then with regard to disk IO. But it’s usable if you don’t play too many notes at once or make extensive use of a sustain pedal. I’ve tested the script with a Class 4 SD though so a faster SD card could improve stability.

Edit: finally got around buying a better SD card and the difference is huge! I bought a SanDisk Extreme Class 10 SD card and with this SD card I can run LinuxSampler at lower latencies and I can play more notes at once.

Before you can run the script on your Raspberry Pi you will need to tweak your Raspbian installation so you can do low latency audio. How to achieve this is all described in the Raspberry Pi wiki article I’ve put up on wiki.linuxaudio.org. After you’ve set up your RPi you will need to install JACK and LinuxSampler with sudo apt-get install jackd1 linuxsampler. Next step is to get the Salamander Grand Piano sample pack on your RPi:

cd
mkdir LinuxSampler
cd LinuxSampler
wget -c http://download.linuxaudio.org/lau/SalamanderGrandPianoV2
/SalamanderGrandPianoV2_44.1khz16bit.tar.bz2
wget -c http://dl.dropbox.com/u/16547648/sgp44.1khz_V2toV3.tar.bz2
tar jxvf SalamanderGrandPianoV2/SalamanderGrandPianoV2_44.1khz16bit.tar.bz2
tar jxvf sgp44.1khz_V2toV3.tar.bz2 -C SalamanderGrandPianoV2_44.1khz16bit
--strip-components=1

Please note that decompressing the tarballs on the RPi could take some time. Now that you’ve set up the Salamander Grand Piano sample library you can download the script and the LinuxSampler config file:

cd
mkdir bin
wget -c https://raw.github.com/AutoStatic/scripts/rpi/piano -O /home/pi/bin/piano
chmod +x bin/piano
wget -c https://raw.github.com/AutoStatic/configs/rpi/home/pi/LinuxSampler
/SalamanderGrandPianoV3.lscp -O
/home/pi/LinuxSampler/SalamanderGrandPianoV3.lscp

Almost there. We’ve installed the necessary software and downloaded the sample library, LinuxSampler config and piano script. Now we need to dot the i’s and cross the t’s because the script assumes some defaults that might be different in your setup. Let’s dissect the script:

#!/bin/bash

if ! pidof jackd &> /dev/null
then
  sudo killall ifplugd &> /dev/null
  sudo killall dhclient-bin &> /dev/null
  sudo service ntp stop &> /dev/null
  sudo service triggerhappy stop &> /dev/null
  sudo service ifplugd stop &> /dev/null
  sudo service dbus stop &> /dev/null
  sudo killall console-kit-daemon &> /dev/null
  sudo killall polkitd &> /dev/null
  killall gvfsd &> /dev/null
  killall dbus-daemon &> /dev/null
  killall dbus-launch &> /dev/null
  sudo mount -o remount,size=128M /dev/shm &> /dev/null
  echo -n performance
| sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor &> /dev/null
  if ip addr | grep wlan &> /dev/null
  then
    echo -n "1-1.1:1.0" | sudo tee /sys/bus/usb/drivers/smsc95xx/unbind &> /dev/null
  fi
  jackd -P84 -p128 -t2000 -d alsa -dhw:UA25 -p512 -n2 -r44100 -s -P -Xseq
&> /dev/null &
fi

This is the first section of the script. An if clause that checks if JACK is already running and if that’s not the case the system gets set up for low latency use, a simple check is done if there is an active WiFi adapter and if so the ethernet interface is disabled and then on the last line JACK is invoked. Notice the ALSA name used, hw:UA25, this could be different on your RPi, you can check with aplay -l.

jack_wait -w &> /dev/null

jack_wait is a simple app that does nothing else but checking if JACK is active, the -w option means to wait for JACK to become active.

if ! pidof linuxsampler &> /dev/null
then
  linuxsampler --instruments-db-location $HOME/LinuxSampler/instruments.db
&> /dev/null &
  sleep 5
netcat -q 3 localhost 8888
< $HOME/LinuxSampler/SalamanderGrandPianoV3.lscp &> /dev/null &
fi

This stanza checks if LinuxSampler is running, if not LinuxSampler is started and 5 seconds later the config file is pushed to the LinuxSampler backend with the help of netcat.

while [ "$STATUS" != "100" ]
do
  STATUS=$(echo "GET CHANNEL INFO 0" | netcat -q 3 localhost 8888
| grep INSTRUMENT_STATUS | cut -d " " -f 2 | tr -d 'rn')
done

A simple while loop that checks the load status of LinuxSampler. When the load status has reached 100% the script will move on.

jack_connect LinuxSampler:0 system:playback_1 &> /dev/null
jack_connect LinuxSampler:1 system:playback_2 &> /dev/null
#jack_connect alsa_pcm:MPK-mini/midi_capture_1 LinuxSampler:midi_in_0 &> /dev/null
jack_connect alsa_pcm:USB-Keystation-61es/midi_capture_1 LinuxSampler:midi_in_0
&> /dev/null

This part sets up the necessary JACK connections. The portnames of the MIDI devices can be different on your system, you can look them up with jack_lsp which will list all available JACK ports.

jack_midiseq Sequencer 176400 0 69 20000 22050 57 20000 44100 64 20000 66150 67 20000 &
sleep 4
jack_connect Sequencer:out LinuxSampler:midi_in_0
sleep 3.5
jack_disconnect Sequencer:out LinuxSampler:midi_in_0
killall jack_midiseq

This is the notification part of the script that will play four notes. It’s based on jack_midiseq, another JACK example tool that does nothing more but looping a sequence of notes. It’s an undocumented utility so I’ll explain how it is invoked:

jack_midiseq

<command> <JACK port name> <loop length> <start value> <MIDI note value> <length value>

Example:
jack_midiseq Sequencer 176400 0 69 20000 22050 57 20000 44100 64 20000 66150 67 20000

JACK port name: Sequencer
Loop length: 4 seconds at 44.1 KHz (176400/44100)
Start value of first note: 0
MIDI note value of first note: 69 (A4)
Length value: 20000 samples, so that's almost half a second
Start value of second note: 22050 (so half a second after the first note)
MIDI note value of second note: 57 (A3)
Length value: 20000 samples
Start value of third note: 44100 (so a second after the first note)
MIDI note value of second note: 64 (E4)
Length value: 20000 samples
Start value of third note: 66150 (so one second and a half after the first note)
MIDI note value of second note: 67 (G4)
Length value: 20000 samples

Now the script is finished, the last line calls exit with a status value of 0 which means the script was run successfully.

exit 0

After making the script executable with chmod +x ~/bin/piano and running it you can start playing piano with your Raspberry Pi! Again, bear in mind that the RPi is not made for this specific purpose so it could happen that audio starts to stutter every now and then, especially when you play busy parts or play more than 4 notes at once.


Using a Raspberry Pi as a piano: quick demo

Using a Raspberry Pi as a piano

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.

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!

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;

Cubieboard2

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

Carla on the Raspberry Pi

Last week I managed to get Carla running on my RPi. Carla is a really nice plugin host that supports the most important plugin frameworks available for Linux (LV2, DSSI, LADSPA and VST) with some awesome extra features like a built-in ZynAddSubFX synth and support for SF2, SFZ and GIG files. The latter didn’t work until yesterday but I managed to compile LinuxSampler (which is needed by Carla in order to be able to load SFZ and GIG files) for the RPi with the help of Paul Brossier aka piem from the Aubio project.

I just wrote him a mail:

Hello Paul,

I’m trying to package LinuxSampler for Raspberry Pi but I’m running into an issue when compiling which fails with a message related to RTMath.h. After some googling I ended up here:
http://bb.linuxsampler.org/viewtopic.php?f=2&t=514#p3156
So I started scouring the interwebs and found this:
http://packages.qa.debian.org/l/linuxsampler/news/20050806T210205Z.html
Where there is a reference to a possible fix. But the diff.gz that contains the patch is untraceable. I know this announcement is almost 8 years old but do you think you still have the diff or maybe an idea what changes you made to the code?

Thanks in advance and keep up the good work with Aubio!

Best regards,

Jeremy Jongepier

And guess what, he replied almost instantly! He gave me some pointers where to add some extra code and even though I’m not a coder I started trying things out. But then I stumbled upon actual patches to resolve this issue. I needed both the ARM and atomic patch and after applying those LinuxSampler compiled flawlessly in my Raspbian ARM chroot. The few lines of code I cooked up myself were almost identical so I got quite far actually. I should really pick up learning how to code, I think I’d learn fast.

So after compiling LinuxSampler I could rebuild Carla against the freshly created LinuxSampler libs. Installed the deb on my RPi and loaded some SFZ’s. It all worked like a charm. Carla is like a Swiss Army Knife, I’m really starting to appreciate this piece of software. Kudos to falkTX! And thanks to Paul Brossier for responding so quickly and helping me to get on the right track.


text-align: center;

Carla running on the Raspberry Pi

Carla on the Raspberry Pi

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: http://elinux.org/BeagleBoardDebian#Demo_Image
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

More ARM goodies

Bought another Android TV stick based on the RK3066 SoC, the MK808 which is as far as I’ve understood kind of the default board to hack on.


MK808 Android TV stick

Also bought a BeagleBone Black development board. Why? Because apparently JACK runs well on it, also with USB interfaces (no need for the ALSA softmode option!) so I assume the USB implementation is better than those of the Raspberry Pi and the RK3066 based board I currently own. And I could get it cheaper over here in The Netherlands than other viable alternatives like the pcDuino or Cubieboard, also because of a coupon code I found on tweakers.net so I got a price reduction of a few Euros. Another reason why I bought it are the so-called capes that are available for this board. These capes are basically add-on boards and the cape that has my most attention is the audio cape. I’m thinking about buying that specific cape, solder two Neutriks on the audio in and out and turn it into the easiest DIY guitar effect box ever. Of course with guitarix loaded on it, the devs have done an incredible amount of work recently to get guitarix running flawlessly and painlessly on ARM dev boards like the BeagleBone Black.


BeagleBone Black


BeagleBone Audio Cape

More ARM goodies