I finally got a Raspberry Pi last week. To my shame I caved in and bought one from Ebay for £57 inc delivery. I think it’s probably still worth that much though. The Raspberry Pi, for anyone who’s been living under a rock, is a credit card-sized ARM-based computer which sells for $35 or about £30 including delivery.
Broadcom BCM2835 SoC
CPU – 700MHz ARM1176JZF ARMv6 (ARM11)
GPU – 250MHz VideoCore IV (OpenGL ES 2.0, 1080p h.264 L4.1 40Mbps, MPEG-4)
SDRAM – 256MB
USB Ethernet controller + 2 USB ports
HDMI + Composite + DSI
8xGPIO, UART, I2C, SPI.
All this is powered from a single 700mA (3.5w at 5v) MicroUSB connection.
I’d been planning to try it out as an XBMC media centre and a Linux/Samba file server. The ARM is a little slow but being able to do H.264 and MPEG4 ASP in should hopefully ensure CPU won’t hold it back too much when playing media.
Getting XBMC on the RasPi was simple, just download a Windows (or Mac or Linux) autoinstaller from raspbmc.com (currently down) which will install a bootstrap to your SD card. You then boot up your RasPi with that in the slot and it automatically downloads the latest build of RaspBMC, installs it onto your card and reboots into XBMC.
The first thing I noticed was that the background images have been removed from the default Confluence skin and replaced with a single static image for all options, I assume this is to reduce memory and CPU load on the poor ARM. The interface is usable, but obviously not as quick as my Atom/ION machine.
Initially I attached the RaspBMC to my XBMC MySQL database, but the interface became a little too slow to be usable. I’ll have to try this again later to see if I can speed it up.
When I came to try some content nothing would play smoothly at 1080p and only about half of the 720p content I tried would play smoothly. It turns out that the ARM CPU just doesn’t have enough grunt to decode the DTS audio found on almost all 1080p and most 720p content. Almost XviD content I tried played fine, one or two had some hiccuping and one or two just refused to play, I think this is probably related to the encoding features used.
The situation is a little better for content played from a USB-attached hard disk or flash drive, but it’s still not quite fast enough to play the DTS streams. It seems that the USB network adaptor is a bit of a CPU hog.
Apparently this is a common irritation for people wanting to use the RasPi as a media centre. That, and the lack of hardware MPEG2 decoding making it impossible to decode many HD broadcast streams. This isn’t an issue for me, and anyone who really needs MPEG2 decoding will probably have other options.
Overclocking and Raspbian armhf
To fix the DTS issue I decided to try to overclock the Pi. It has a little headroom for overclocking, the creators say that almost all Pis should be able to hit 800MHz and many are reported to go much faster.
See the post on Raspberry Pi Overclocking for more details.
The highest overclock I achieved which was stable in XBMC was 1050MHz on the ARM core, 450MHz on the RAM and 500MHz on the GPU core. At those speeds the Pi still couldn’t quite decode DTS audio streams.
I also installed Raspbian, which uses armhf and provides a significant performance improvement on the RasPi. See the post on Raspbian Benchmarking – armel vs armhf for more details.
I tested the performance of the Pi at decoding various audio formats on the armel and armhf architectures and with the stable clock. The chart above shows the %age of CPU required to decode the various audio formats in real time.
Using Raspbian overclocked to 1GHz and my XBMC binaries I was able to play back a relatively high-bitrate H.264 (~20Mbps) video file with 1.5Mbit DTS audio successfully from a USB hard disk and from a local samba file server with relatively high success rates, but still not perfectly. There still seems to be problems when the video bitrate goes above ~20Mbit. Note that the core_freq=500 overclock was important, without it the playback still stuttered.
Below are the config.txt settings for my highest stable XBMC overclock.
I finally decided that I would transcode all of my DTS audio-streams to an alternative format so that they’ll play properly on the RPi over the network. I’m no audiophile and I don’t have a fancy home theater setup, so I decided to transcode all of the audiostreams to 192Kbps stereo AAC, which should surpass 256Kbit MP3 in quality. If you wanted to retain your 5.1 surround you could use 5.1 448Kbps AAC, which the RasPi seems to be able decode without issues.
I modified a shell script used to transcode DTS to AC3. It scans the MKV container and upon detecting a DTS or AC3 file converts them to AAC and re-merges the MKV. I copy the original MKV into a large ramdisk first, as the entire file has to be scanned 3 times during the process.
Transcoding from DTS to AAC can save about 1GB on an average 2 hour file.
Original Filesize: 4,578,516 KB
Extracted DTS Filesize: 1,024,072 KB
Converted AAC Filesize: 114,224 KB
Final Filesize: 3,666,592 KB
Transcoding from AC3 to AAC will save 2-400MB.
Original Filesize: 4,575,228 KB
Extracted AC3 Filesize: 513,364 KB
Converted AAC Filesize: 135,036 KB
Final Filesize: 4,194,832 KB
The transcoding is relatively quick, a 2-3 minutes for AC3 and 5 minutes for DTS.
Of course, none of this would be an issue if you have a DTS/AC3-capable audio decoder, as then the audio would be passed through to the decoder with no processing done on the RasPi.
After an hour’s effort of modifying the script and testing it, I’ve now got a perfectly usable and very low media centre device and as a bonus a shed load of newly-freed up storage space!
I’m quite impressed with the Raspberry Pi so far, even given its shortcomings. I intend to carry one around with me when I’m using hotels so that I can play movies on the hotel TV. I also plan to take a couple to Mexico with me the next time I go over there to act as media centre and file servers in the house.