Blog

New Nerdy Project: Inky Impression Picture Frame

The other day (coincidentally, on Pi Day) I posted on Mastodon about picking up some new Raspberry Pi and accessories for a couple of new projects.

Well, this is the first one! I’ve constructed an e-ink picture frame.

Over on YouTube, AKZ Dev has recently posted a few videos about the hardware I’m using: a 7.3″ e-ink display from Pimoroni called the Inky Impression.

He’s also been writing some python software to power it, and while I’m sure what he’s created is great the point of this project for me is as a learning exercise, so I’ll be writing my own code.

Hardware

First of all though, I had to assemble the hardware. This is pretty straight-forward:

I may still get a wooden picture frame to put this in for better aesthetics, but for now my 3D printed version is working great. You put the Pi into its 3D printed case, the display into its 3D printed case, and then you plug them together and give it some power. Done!

I wish that the colours on the display were a little more vibrant than they are (this aspect of the display is not quite as good as I was expecting it to be) and I wish it updated a little more quickly (this is exactly as I expected it to be, and it takes about 30 seconds), but on the whole I like this e-ink display much more than I like backlit LCD photo frames.

Software

I downloaded my new favourite OS for the Raspberry Pi, DietPi, as a base and let it guide me through the setup process to connect to WiFi, set the timezone, the usual stuff. A couple of particular options to pay attention to during setup were to enable I2C and SPI, which is how the Pi communicates with the screen through the GPIO header, and install a NodeJS environment which I did simply by selecting it from the DietPi software installer.

Pimoroni suggests Python as the language to use and offers a Python library for that purpose, but I have limited experience in Python and I’m much more comfortable with Node, so that’s what I’m going to use if I can.

As a proof of concept, I wrote a half-dozen lines of code that take an input image, resize and crop it to fit the display, and render it on the screen. I’m using the sharp library for the image manipulation, and the inky library from aeroniemi to interact with the display.

const sharp = require('sharp')
const inky = require('@aeroniemi/inky')
const frame = new inky.Impression73()
sharp('../img/OriginalImage.jpg')
  .resize(800, 480)
  .toFile('output.png', (err, info) => {
	frame.display_png('output.png')
	frame.show()
})

So far this is working great. I obviously plan to extend this, and I’ll make the eventual code available if anyone else wants to replicate what I’ve done. Features I’m currently thinking about are:

  • Connect to a specific album in my Google Photos account
  • Rotate through the images in the album, updating every five minutes or so
  • Ability to skip forward and back using the buttons on the side of the display, maybe
  • Ability to skip forward and back by issuing a command over MQTT (of course I’m integrating this thing with Home Assistant)
  • Ability to display some specific content (other than the usual album) based on an MQTT command or button press… what I’m thinking of here is my WiFi username and password that I can interrupt the slideshow to display for guests along with a QR code with the connection details
  • Maybe the ability to display a webpage by loading it headlessly and taking a screenshot (I believe AKZ Dev’s software can do this and it seems like it opens up lots of possibilities)
  • Maybe a REST API in case I want to use that rather than MQTT

This’ll all take me some time and I’m not in a rush, but I’ll post more as I work on it!

Shrapnel

Earlier in the week I wrote a blog post about how I set up my Office display using a Raspberry Pi 3B+

Today I picked up a Pi 4 and a Pi Zero 2 W for other projects (watch this space!) and I was curious how they’d perform. So I raced them. From the time I press the “power on” button on my TV remote to the time they’re displaying a webpage.

DeviceTime
Raspberry Pi 3B+1:05
Raspberry Pi Zero 2 W1:25 (+20 secs)
Raspberry Pi 4B (4gb)0:49 (-16 secs)

This is not super-scientific. I think the 3B+ is usually faster except it took longer than usual to obtain an IP address during its boot process. šŸ¤·šŸ»ā€ā™‚ļø

What was most interesting to me was the differences between the 3B+ and the Zero 2W: the initial parts of the Zero’s boot process were quicker than the 3B+, but as soon as it got into dealing with graphics and opening the browser it slowed down dramatically. Even changing from one screen to another in my dashboard and reloading page elements were slow enough that I would need to change my dashboard layout. It really wasn’t performant enough for what I’m doing.

The Pi 4, unsurprisingly, performed great – although the difference between the 3B+ and the 4 wasn’t as big as I thought it would be. The Pi 4 is also too power hungry to be powered by my TV’s USB port, which is a really nice feature of my setup.

Whether by luck or judgement, the setup I have is the one I’d recommend if you want to do something similar. I’m almost tempted to buy more Pi 3s in case I want to replicate it somewhere else in the house.

Blog

How to build a dashboard display with a Raspberry Pi

Skip intro >>

In my office I have a TV on the wall that shows me some pertinent info about whatā€™s going on with our house (thanks to Home Assistant and our array of Smart Home sensors) and the weather, and rotates the display between my calendar, a Google Map with the local traffic overlay, and a view of our security cameras.

Iā€™ve had it for many years and I set it up by (mostly) following a 2016 guide.

The whole thing runs on a Raspberry Pi 3b which I love because I can power it using the USB port built into my TV. The low-power hardware makes optimization critical, hence why the Pi is set up with just enough software to run a lightweight web browser and nothing more.

Iā€™ve recently been on a bit of a journey of switching to Linux for almost all my computing – more to come on that in a future post – which has led me to go through all my devices one by one and get them set up the way I wanted. That inspired me to take a crack at the office Pi too.

It was working just fine before I touched it so I wasnā€™t necessarily expecting to make any changes, but I thought it might be good to see if the software options identified nine years ago are still the most optimal.

No theyā€™re not as it turns out, so hereā€™s my updated guide on setting up a Raspberry Pi to display a web page (and nothing more, nothing less).

The Operating System

My first change was the base operating system. I switched to DietPi. Download the image for your particular device and install it. There are instructions on the DietPi site if you need them.

Work through the DietPi setup process that automatically launches when you first boot the drive and log in, in particular:

  • Set the localization options (keyboard layout, system locale, timezone)
  • Connect to the internet – in my case I used the Pi’s built-in WiFi – and optional but recommended: disable any connections you won’t be using (e.g. wired Ethernet) so they don’t slow the boot process
  • Enable SSH if you want it
  • Set autologin as root – generally it would be good practice not to use the superuser account for day to day operation and instead set up another account with only the privileges needed, but this setup is so basic we’re not going to worry about it
  • Don’t install any of the software packages – we’re going to carefully install only what we need

For some reason my networking settings didn’t take effect on first setup and I had to reboot and repeat that part of the setup by launching dietpi-config from the command line.

The Software

Our goal with the software we install is two-fold:

  1. If we don’t absolutely need a piece of software, we’re not installing it
  2. We want the software we are going to install to be as lightweight as possible

All we want to do is display a web page on a display. We don’t even really need users to interact with our system. To get this done we’re going to need an X server, a window manager, a web browser and couple of utilities to tie everything together. Let’s get it installed:

apt update
apt upgrade
apt install xserver-xorg x11-xserver-utils dwm surf xinit unclutter

We’re using the X.Org X server, the dwm window manager and surf browser (both from suckless.org), and we’re installing unclutter to hide the mouse pointer when it isn’t in use.

Configuration

First we’re going to create a startup script: nano /root/startdisplay.sh

#!/bin/bash
# Disable DPMS (Energy Star) features.
xset -dpms
# Disable screen saver
xset s off
# Don't blank the video device
xset s noblank
# Allow quitting the X server with CTRL-ATL-Backspace
setxkbmap -option terminate:ctrl_alt_bksp
# Disable the mouse pointer
unclutter &
# Run window manager
dwm &
# Run browser in full-screen mode
surf -F https://www.google.com

Replace https://www.google.com above with the URL of your dashboard, then press Ctrl-O to save the file followed by Ctrl-X to exit nano. Next, make the script executable:

chmod +x /root/startdisplay.sh

Finally, edit /root/.bashrc and add the following three lines at the end:

if [ -z "${SSH_TTY}" ]; then
  xinit ~/startdisplay.sh
fi

This will start X and run our startdisplay script when the root user logs in directly to the device, but not if they’re logging in over SSH (where it wouldn’t work anyway).

And that’s it, done! Reboot your Pi and enjoy your display.

My Pi3B takes around 45 seconds from power on to the point where it’s displaying my dashboard web page, which is less than half the time the previous software setup took (the hardware has remained the same throughout).

The Exciting Conclusion

I’d love your feedback on all this. Is there an even more efficient setup I’m missing? I’d also love to hear about your use case.

Blog

Smart Home Dashboard

[youtube https://www.youtube.com/watch?v=8N087dKoKno?feature=oembed&enablejsapi=1&origin=https://safe.txmblr.com&wmode=opaque&w=540&h=304]

Recently, I have been all about turning our home into a smart home. Thatā€™s mostly because Iā€™ve discovered Home Assistant: a little piece of software that runs (in my case) on a Raspberry Pi and pulls together data from all the sensors and smart devices you own.

Apart from a new WiFi thermostat that I was going to buy anyway I havenā€™t yet spent any money at all in my quest for this – Iā€™ve merely connected together the devices we already owned (Chromecasts; family room lights; our burglar alarm), added in some data available through various APIs (weather; internet speed; server status) and pulled location information from our phones using an app that publishes the information to my own server.

Anyway, now that I have all this information in one place I wanted an attractive way to display it in my office. Happily Iā€™d already bought a monitor with a built-in powered USB hub from a surplus equipment sale a while back, with this kind of project in mind.

So, my Friday afternoon project today became hooking up another Raspberry Pi to this monitor and crafting a HTML dashboard for it to display. Not everything works yet, but I think itā€™s pretty good for an afternoonā€™s work.

(Since I didnā€™t remove the clock from the frame when I shot the video, I canā€™t pretend this thing is quick to boot. I may have manipulated the video speed at a couple of points. But anyway).

Oh, and watch this space for some home-brew smart home devices, coming soon!

Blog

Raspberry Pi Whole Home Audio: The Death of a Dream?

If youā€™ve been following my blog for a while, youā€™ll know
that Iā€™ve written a whole
series of posts
on my efforts to take a few Raspberry Pis and turn them
into a DIY whole home audio solution.

If youā€™ve ever looked at the product offering within the
whole home audio space, youā€™ll know that setting such a thing up is either
cripplingly expensive, involves tearing the walls apart to run cables, or both.

Where we left off Iā€™d put together a solution that was
glorious when it worked, but that was rare. Typically the audio was either out
of sync between the devices right from the get go, or quickly got that way.

Getting the Pis to play the same music was relatively
simple, but getting it perfectly in sync so that it could be used in a
multi-room setup eluded me to the end, and eventually I gave up.

The bottom line is that synchronizing audio between multiple
devices in a smart way requires specialized hardware that can properly account
for the differences in network latency between each of the end points. The Pi
doesnā€™t have that, and itā€™s not really powerful enough to emulate it through
software.

So is my dream of a reasonably priced whole home audio
solution dead? Hell no.

In October I wrote
about Googleā€™s announcement of the Chromecast Audio
. At the time it didnā€™t
have support for whole home audio but Google had promised that it was coming.
Itā€™s here.

The day they announced that it had arrived was the day I
headed over to my local BestBuy and picked up four of these things. I plan to
add two more, and I couldnā€™t be happier with the results.

Plus, it frees up the Pis for other cool projects. Watch
this space!

Blog

Raspberry Pi Whole Home Audio ā€“ The Conclusion?

Welcome to what is possibly the concluding post in my Raspberry Whole Home
Audio Project
series of postsā€¦ or possibly not.

At the start of this journey I had a plan to install mopidy on one of my Raspberry Pis and use pulse
audio
to stream the output to the others. Along the way I ran into some challenges
stemming from me buying the cheapest peripherals I could (and subsequently needing
to upgrade the WiFi adapters and power cables I first bought to better ones),
and my vision evolved as things progressed.

Instead of using mopidy, I switched to installing Kodi on each of the Pis thanks to the OpenElec linux distribution thatā€™s available for
several types of hardware, the Pi included.

image

Kodi, as a full-blown media centre system, might seem like a
bit of an odd choice for a headless device (i.e. something with no attached
display), but itā€™s the right choice for me for a couple of reasons.

  • I already have it installed on a couple of PCs
    in the house, attached to the TVs in the living room and the bedroom
  • I already have a remote
    control app
    for it on my phone
  • There are plugins for a bunch of stuff, such as this one for my favourite music streaming service. Well written
    plugins integrate perfectly with the system, and the remote control app.
  • It has built-in support for acting as an airplay
    receiver

For me, these things combine to provide me with the best of
both worlds. If I just want to play music from my library or from an internet
streaming service on one set of speakers, then I fire up the remote app and
target the particular device I want to output from.

If I want to play the same thing on several (or all) the
devices at the same time, then I fire up TuneBlade
on my laptop and any sounds that would usually come out of its speakers get
redirected to all the airplay receivers.

image

When it works, itā€™s glorious. Having the same music playing
in sync on all the speakers in the apartment is awesome.

The problem is that it doesnā€™t always work. TuneBlade
includes a setting that lets you set how much of a buffer you want. If you set
it too high the devices wonā€™t synchronize because it will take a slightly
different amount of time to fill the buffer on each of them. I have it set to
zero, which works amazingly well most of the time but leaves me especially
prone to blips in network connectivity and bandwidth. When these occur, things
get out of sync (which sounds terrible, because each set of speakers is not all
that far away from its neighbours), and it canā€™t seem to automatically recover ā€“
I have to manually disconnect and reconnect the affected player to get it back
in sync with its peers.

The bottom line then is that my setup is good, but not
perfect. Itā€™s no Sonos.

The search for a perfect system will likely continue, but
for the time being Iā€™m pretty content. I spent less than $100, and I have a
setup that would have cost me $5,000 from them.

Blog

Raspberry Pi Whole Home Audio Updates

Itā€™s been a long time since Iā€™ve written about my Raspberry Pi Whole Home Audio Project.

Simply, thatā€™s because Iā€™ve hit a bit of a wall and Iā€™m especially busy with work right now so I havenā€™t been able to find the time to work my way around it.

The problem is that the USB WiFi adapters that I bought (for about $5 each) donā€™t perform well. They have signal strength issues, and while they do work and maintain a network connection, the poor signal strength means the connection isnā€™t fast enough to stream audio. There are plenty of other people out there having the same problem. You get what you pay for, I guess, and I need to buy replacement adapters.

Iā€™m also considering a change in direction. My original plan was to install mopidy on one of the Pis and use pulse audio to stream the output to the others.

Iā€™m considering instead installing TuneBlade on one of my Windows PCs. TuneBlade takes all the audio output from that computer and streams it using Appleā€™s AirPlay protocol. Iā€™d then install ShairPort on all the Pis to turn them into AirPort receivers.

What do you guys think?

Blog

Raspberry Pi Whole Home Audio: Playing Music

Itā€™s very rare that I tweet teasers to my blog post, but
last weekend I was so excited to be making progress on my Raspberry Pi Whole
Home Audio
project that I told the world Iā€™d be publishing this one on
Thursday.

Here we are on Friday morning. Thereā€™s doubtless a lesson in
here for me about making promises I canā€™t keep, but Iā€™m hoping youā€™ll forgive
me when you read about what Iā€™ve done.

If youā€™ve been following my #RPiWHA Project
hashtag on this blog then youā€™ll know that when we left off last time I had
three Raspberry Pis networked together with synchronized clocks, and one of
them had access to the internet and the music library I keep on my home server.
Thatā€™s important, but not especially exciting. Today weā€™re going to move in a
more exciting direction, though.

Today weā€™re going to put Pis #2 and #3 aside, but weā€™re
going to get Pi playing music!

Specifying and Testing the Piā€™s Audio Output

The Raspberry Pi has two options for audio output. It has a
3.5mm analog output, and digital output through its HDMI port. It decides which
output to use automatically ā€“ if you have a HDMI monitor plugged in then the Pi
will detect this and assume you want to use HDMI for audio too.

Thatā€™s not the situation for me (my Pi is ā€œheadlessā€ and
doesnā€™t have a display connected at all), and audio comes out of the 3.5mm
output automatically ā€“ which is what I want. If you need to specify, you can
run:

sudo amixer cset numid=3 1

The digit 1 at the
end means the Pi should use the analog audio output. Putting 0 there instead would mean auto-detect
(the default) and putting 2 would
mean digital output over HDMI.

Plug in some headphones or speakers and run:

aplay /usr/share/sounds/alsa/Front_Center.wav

You should hear a voice saying ā€œfront centre.ā€

Install Mopidy

Weā€™re going to install music playing software called mopidy.
It provides a web-based interface so you can control your music, or there are
controller apps available in your app-marketplace of choice. Mopidyā€™s website
takes you through the
install process in detail
, but Iā€™m going to summarize the commands here:

wget -q -O - https://apt.mopidy.com/mopidy.gpg | sudo apt-key add -
sudo wget -q -O /etc/apt/sources.list.d/mopidy.list https://apt.mopidy.com/mopidy.list
sudo apt-get update
sudo apt-get install mopidy python-setuptools

Done! We now have a basic install of mopidy, and the especially
astute amongst you will have noticed that weā€™ve also installed a package called
python-setuptools. Mopidy is written
in the python programming language, and the latter package is going to help us
with installing and setting up some mopidy extensions in an automated way. The
first thing weā€™re going to do is install something called pip, which is a tool for installing python packages:

sudo easy_install pip

Now that we have that, weā€™re going to in turn use pip to
install some mopidy extensions:

sudo pip install Mopidy-MusicBox-Webclient
sudo pip install Mopidy-WebSettings

With those commands weā€™ve added a web-based interface to our
player so we can control it from a browser on another computer or mobile
device.

Setting Up Mopidy

Weā€™re almost ready to start mopidy and try things out, but
there is a little bit of initial setup to be done first. Edit the file ~/.config/mopidy/mopidy.conf. In the http section, change the following line
so that the web interface becomes accessible to any device on your network:

hostname = ::

In the local
section, tell mopidy where it should find your music library. In my case:

media_dir = /mnt/music

Save the file and exit. The next step is to tell mopidy to
scan your music folder:

mopidy local scan

If, like me, you have a large music collection stored on a
network share, be prepared for this to take a very long time. I started it
running before I went to bed, and it eventually completed the process about 45
minutes after I got up the following morning.

When itā€™s done though, weā€™re ready! Run mopidy:

mopidy

Itā€™ll take a little while to fully start up, but when you
see the line

INFO     HTTP server running at [::]:6680

that means weā€™re good to go. Open the browser on your
computer or mobile device and point it to
http://192.168.1.71:6680/musicbox_webclient (replace 192.168.1.71 with the IP
address of your Pi as appropriate). Go to Browse, Local Media, and select a
song!

If all is well the music will be playing through the
headphones or speakers attached to the Pi, and weā€™re all done until the next
installment ā€“ rerouting the audio from Pi and streaming it, synchronized, to
Pis #2 and #3 instead.

Enjoy!

Blog

Browse Anonymously with a DIY Raspberry Pi VPN/TOR Router

So, after last week’s post about preparing my Raspberry Pis for my whole home audio project, I had three Pis that should have been set up properly, but weren’t working very well – and the culprit was the USB WiFi dongles I was using.

Happily a stumbled upon the article linked above, and it solved the issues I was having!

Surf the Internet securely with your very own portable WiFi VPN/TOR router. You can configure a Raspberry Pi with Linux and some extra software to connect to a VPN server of your choice.

I didn’t follow all the steps because they’re doing something different to me, but there is some commonality and, crucially, the article folks are using WiFi adapters with the same chipset that mine have. Step four shows you how to download and compile a version of hostapd that’s built especially for them and works well. I’ve updated my previous post with these steps.

Now that I have networking all set up I’ve taken a couple of extra steps:

  • I set up passwordless ssh between the three Pis. This isn’t required for my solution per se, it just makes things easier.
  • I used sshfs on pi to connect it to my existing home server, and mount the folder that holds all my music.

I’m excited to move on to next steps! The prep work was necessary, but it didn’t make for an especially interesting blog post because it’s all a bit dry.

Keep following my #RPiWHA Hashtag! The next installment will be more interesting, I promise. We’re going to get some actual music playing!

Browse Anonymously with a DIY Raspberry Pi VPN/TOR Router

Blog

Raspberry Pi Whole Home Audio: Preparation and Networking

At the start of the month I announced my plan to try and build my own whole home audio system using a handful of Raspberry Pis to act as the player and audio
receivers. Iā€™ve received
all the stuff I need
now, and Iā€™m ready to get to building!

The first thing Iā€™m doing is preparing the Pis and setting
up networking. Next Iā€™m going to install audio playing software with a
web-interface on Pi number one, and thirdly Iā€™ll adjust the setup so that this
player sends itā€™s audio to the other two Pis (the receivers) instead of
outputting it directly to its own speakers. You can follow the whole journey by
following the #RPiWHA
Project
hashtag right here.

Installing Raspbian

Raspbian is the Raspberry Piā€™s recommended operating system.
Thereā€™s plenty of guidance online on how
to install it
, so I wonā€™t reiterate the whole process here. When I ran
through Raspbianā€™s initial setup options on first boot I set my location,
timezone and keyboard layout (in Internationalisation Options), set the memory
split to 16mb for graphics (in Advanced Options ā€“ we can set this low because
we wonā€™t even be connecting a display) and finally expanded the filesystem
(right from the main menu).

Minimizing SD Card Access

The Pi has no power button. If itā€™s plugged in then itā€™s on,
and you turn it off by pulling the plug. Iā€™ve read online that if the power is
pulled while the system is in the process of writing to the Piā€™s SD card (which
is the only storage the system has) this can cause problems and possible
corruption.

Linux systems do a lot of logging, most commonly to the
folder /var/log. They also write stuff about running process to the folder
/var/run. To minimize writes to the SD card, weā€™re going to mount these two
folders in memory instead of on the card. Another cause of frequent writes is
that linux systems store the time that a file was last accessed, so even if weā€™re
just reading a file the system is actually writing back to the disk to update
the time that the file was accessed. Weā€™re going to change that behaviour too.

To make these changes, weā€™re going to edit the file
/etc/fstab so that it looks like this:

proc            /proc           proc    defaults          0       0
/dev/mmcblk0p1  /boot           vfat    defaults,noatime  0      2
/dev/mmcblk0p2  /               ext4    defaults,noatime  0      1
none            /var/run        tmpfs  size=1M,noatime   0       0
none            /var/log        tmpfs  size=1M,noatime   0       0

The first two lines havenā€™t changed, but on the third line
weā€™ve added the flag ā€œnoatimeā€ to indicate that we donā€™t want to store the
timestamp that the file was last accessed. The fourth and fifth lines are
entirely new, and these create 1mb partitions in RAM to house the /var/run and /var/log folders respectively.

Setting Up Networking on Pi

The next step was to connect one of the Pis (and only one)
to my existing home WiFi network. To do this I plugged in one of my USB WiFi
adapters and modified the /etc/network/interfaces file to include the
following:

auto wlan0
allow-hotplug wlan0
iface wlan0 inet static
wpa-ssid MyHomeWiFiName
wpa-key-mgmt WPA-PSK
wpa-group CCMP TKIP
wpa-pairwise CCMP TKIP
wpa-psk MyHomeWiFiPassword
address 192.168.1.71
netmask 255.255.255.0
gateway 192.168.1.254
dns-nameservers 192.168.1.53 192.168.1.254

Your setup will probably be slightly different, but
essentially this connects to my home network, gives the pi a static IP address
(192.168.1.71 in my case) and defines my two DNS servers.

You may be wondering why Iā€™m only doing this on one of the
Pis, given that they all need to be connected together. The reason is that this
first pi (the player) is ultimately going to be sending audio out over the
network as multicast packets. In other words, this data goes to every device on
the network whether they want it or not.

The problem is that this is a lot of data flowing around, and
a typical home WiFi network struggles under the load of it all. My solution is
to have two WiFi networks. The one weā€™ve set up above will connect us to the
internet (for streaming audio services) and other stuff on my network (like the
fileserver where my music collection lives), but weā€™ll use a second, separate
WiFi network to send the multicast audio to other Pis.

Letā€™s plug in a second USB WiFi adapter to the first Pi, and
make some more additions to the /etc/network/interfaces file:

auto wlan1
allow-hotplug wlan1
iface wlan1 inet static
address 192.168.5.1
netmask 255.255.255.0

This section is pretty minimal as you can see, but itā€™s
setting a static IP address on the second wireless interface. The important
part is that this uses a different subnet to the other WiFi network (in my
case, 192.168.1.x is my existing network, 192.168.5.x is the dedicated network
for the Pis).

This section of the /etc/network/interfaces file is so short
because this Pi is going to act as a wireless access point that the others will
connect to. To set this up we need an additional bit of software, called
hostapd. Because I’m using WiFi adapters based on a Realtek 8188 chipset, I had to download and compile this myself – the version found in the debian software repositories wouldn’t work for me:

wget https://github.com/jenssegers/RTL8188-hostapd/archive/v1.1.tar.gz
tar -zxvf v1.1.tar.gz
cd RTL8188-hostapd-1.1/hostapd
make
sudo make install

Then edit the file /etc/hostapd/hostapd.conf to change the following three lines:

interface=wlan1
ssid=PiWHA
wpa_passphrase=mySecurePassword

Finally, start the service and add it to the boot autostart services for future:

sudo /etc/init.d/hostapd start
sudo update-rc.d hostapd enable

Setting Up Networking on the Other Pis

We want the other Pis to connect to the wireless network
hosted by Pi . To do so, plug one USB WiFi adapter into each and modify the
/etc/network/interfaces file on each to reflect the following:

auto wlan0
allow-hotplug wlan0
iface wlan0 inet static
wpa-ssid PiWHA
wpa-key-mgmt WPA-PSK
wpa-group CCMP TKIP
wpa-pairwise CCMP TKIP
wpa-psk mySecurePassword
address 192.168.5.2
netmask 255.255.255.0

The important point here is that the IP address for each
must be unique, and must be on the same subnet (192.168.5.x) that we set on the
first Pi.

Setting Up Time Synchronization

The Raspberry Pi has no real-time clock, and instead it gets
the time from internet time servers at boot. Having the time synchronized on
each of our Pis is going to be important to make sure that they play music in
sync. Only the first Pi has a connection to the wider internet though, so we
need to take some additional steps. On Pi , edit the file /etc/ntp.conf and
uncomment (or add) the following line:

broadcast 224.0.0.1

This tells the pi to broadcast a time signal out onto the
network using a special multicast IP address that the other Pis will listen
for.

On the other Pis edit the same file, but uncomment (or add)
the following lines:

disable auth
broadcastclient

We donā€™t need to tell the other Pis which multicast IP
address to listen for ā€“ they already know as part of the NTP protocol.

And Weā€™re Done! Or Are We?

That was a lot of setup work, but we should now have our Pis
setup and networked together, with our player device having an additional
connection to the wider internet.

The thing isā€¦ I donā€™t. The setup is all correct, but the
cheap USB WiFi adapters I bought from China donā€™t properly support access point
mode. Sometimes things work, sometimes they donā€™t.

Iā€™ve read that I can download driver source-code from the
adapterā€™s manufacturer and compile the driver myself, so Iā€™m going to try this
before I go further.