About a month ago, we took our first look at running Sourcefabric’s Airtime on a Raspberry Pi. The idea of running a radio station from a $35 device while managing it from a remote web browser was very intriguing, and we immediately began to experiment with our own Pi as soon as it arrived.
The original Raspberry Pi came with only 256MB of memory, which we came to conclude was not enough to run a default install of Airtime. Too many processes tried to claim the limited memory which led to swapping and ultimately a completely unresponsive device as the system’s slow SD card attempted to serve as extra memory.
So what could we do to get Airtime running on the Raspberry Pi? One idea was to tinker with the database system. Airtime uses Postgresql - a very powerful and quick database, but perhaps too heavy for a Raspberry Pi. In our original article, we found that Postgresql could consume almost half of the Pi’s limited memory. Perhaps we could rewrite Airtime to use SQLite? The problem with this is that although SQLite would consume less memory, it would definitely be slower than Postgresql, and processor speed is another limiting factor of the Pi.
It was during this time that another option presented itself - the Raspberry Pi foundation announced the new default configuration for all Raspberry Pi’s would be 512 MB - at the same $35 cost.
512MB gave us a lot more leg room, and now that we have one in our hands, we took another look at the Pi + Airtime.
Our first trial was to simply install the Airtime Debian package which installs Airtime with the same settings as on a server grade machine. But would performance be acceptable?
Loading the login screen and entering our credentials gave us our first impression - it took almost 20 seconds to login. Once we hit the landing page of Airtime - the Now Playing screen, we noticed the browser was making background requests to the Pi for status updates, and these requests were failing. Essentially, the Pi was already overloaded by one user attempting to receive status updates on an empty schedule.
So where do we go from here? First we could try getting a faster SD card. The SD card we were using for the Pi was an old class 4. We decided to replace it with a new 8GB SDHC UHS-1 class 10 card, which was rated for great read/write speed. We loaded up Airtime on this card and relaunched our login test - speed was almost exactly the same. A quick look at the Raspberry Pi forums confirmed that the Pi couldn’t take advantage of the full speed of newer SD cards, and some class 4 cards performed as well as the class 10 cards.
So what about the software stack? What could we improve there? One method is to use a PHP accelerator. Traditionally PHP code is compiled from source code into machine code for each browser request - a relatively expensive operation. By simply installing a PHP accelerator, this source code is compiled only once, and frees up the Pi to skip directly to running the machine code instead of compiling it first. The PHP accelerator we used is the official PHP project accelerator “APC”. Speed improvements from 2x - 7x are not uncommon. In our case, login time dropped to about 4 seconds - a 5x improvement! However, the landing page status updates still created a backlog on the server as new poll requests piled up on still unanswered previous ones.
These speed improvements were nice, but what else could we do to make the Pi an operational and responsive stand-alone radio station?
Our next target was the HTTP server software. Could we gain some additional speed by trying something different here? By default, Airtime uses Apache server with PHP integrated (modphp), which is known to be one of the slower setups out there. This setup is still in common use due to how easy it is to configure and maintain. A much faster setup is the Nginx server with PHP running as a separate process (php-fpm). So how much quicker was this setup?
A login test showed the landing page loading in at about 1.5 seconds - another significant speed increase, but more importantly, the landing page did not overload the Pi with its constant requests for information. Now we made some progress! Everything was running fully functional:
However, running various tasks in the Airtime interface such as scheduling shows, dragging tracks into or editing shows in realtime felt sluggish.
What’s another way to improve the Airtime and Raspberry Pi? Why not dive into the Airtime software itself? The next installment of this blog series will focus on optimizing the Airtime code to better cater to the Raspberry Pi’s limited hardware needs. At the end of the next post, we hope to have a fully functional, responsive union of Airtime and Raspberry Pi as well as a claim to the world's smallest, cheapest and most powerful radio station.