Design Document for Low-Cost Multi-Room Streaming Audio Solution
The primary aim of this project is to provide a low cost, multi-room streaming audio solution with an easy to use control system that runs on a low cost hardware platform (e.g. Raspberry Pi). The problem that I aim to solve is that multi-room audio solutions are often expensive, usually involving cable routing and expensive hardware. This solution should be low-cost and simple enough to be installed and used in homes by anyone and configurable enough to be of use in businesses (such as nightclubs, bars and any other business that has a need for a multi-room audio solution).
The connected home is a market that is currently growing and this has caused a surge in commercial products and hobbyist projects focused in this area. Whilst some of these products are well made and provide a good experience, they can be expensive to the consumer. For example, many current wireless audio solutions are all in one solutions including the speakers and the wireless connectivity, these are often expensive and for the consumer, the current audio solutions they have lose value as they cannot be used in unison with the wireless solution. One of the key advantages of this project is that the consumer only pays for the cost of the hardware (e.g. Raspberry Pi) and can use their existing audio solutions (with a line in connector), this should equate to no more than £40.
Due to the short amount of time that I have been given in order to complete this project I will be using MoSCoW prioritisation provided by the MoSCoW method to prioritise the requirements of the applications, ensuring that I start with a work solutions and continue to work other features as time allows. Below is a table of requirements sorted into the MoSCoW categories:
Select track to play on each device
Select which device should play what, this is for when party mode is not active.
Synchronised audio playback (Party Mode)
Must be capable of synchronised audio playback between 2 or more devices of mp3 files.
Manual Master / Slave ability
Devices must be able to either be assigned as a Master or Slave device. The master device will provide the clock (for party mode) and playback commands to the slave devices on the network.
Command line facility
The software should be capable of being started via the command line
Service Discovery Mechanisms
The Devices on the network should be capable of discovery and configuration without user interaction. For example, if a master device has been set-up, a new slave entering the network should automatically discover the master and be available to use straight away. A manual override function will also be available for users who are unable to use the service discovery, or want more advanced options.
Local web / cloud user interface
A web interface for the system should be available for use by the user. This interface will allow the user to fully control the system installed including the setup of device names and the content being played through the device.
Ready built Linux SD card image
A fully built image that when copied to an SD card is ready to be used will be created. All the user needs to do is start it up and it should work.
A packaged version
A packaged version of the final solution could be available that can be installed on practically any Debian system. This could be hosted on a repository.
Cross platform setup tool
To ease user setup of the master device on the network, a standalone cross-platform setup tool could be provided, written in Python. This would simply allow the user to initially setup the master device without explicitly knowing the device’s IP address. This would be particularly important if continuing down the cloud control route.
Automatic music discovery
To allow the user access to their music collection easier for playing over the devices. This would scan either a network location specified by the user, a USB memory device or other network provides such as UPnP & bonjour, displaying the artist, album, etc.
“Play Group” functionality
This would allow users to select groups of devices and name this group, then play specific content only on those devices whilst playing other content on another group.
Due to the short amount of time that has been assigned to complete this project in, tight security improvements will not be possible. However with more time the system would use public/private key exchanges in order to provide authentication, confidentiality and integrity.
Below is a list of the modules that the application may include:
This module will consist of two sections, the first will be to create the playback element and share it’s clock and the second part will be used to play the audio. This module will be in use on the master device and will control the local playback and the playback of the other devices. This module will also work as a slave device, allowing audio to be played through this device and allowing it to be selectable by the user.
The module will be in used on each of the slave devices to create the playback element, sync this with the master clock and play the audio.
This module will most likely only be used by the Master device and will take commands either directly from the user (via a local web interface) or via a cloud based web interface.
This module will only be implemented if the cloud route is taken in controlling the device. This module will provide a web interface for the user, and will also be connected in some way to the master device in order to exchange messages (such as new media, device offline, play, pause and stop instructions).
This module will complete two primary tasks, the first will be to advertise the master device and the other will be to search for a master device on the network. This will allow the initial exchange of information over the network without user interactions.
This module will be used in order to scan the music on either a shared network location or on a USB media device attached to the Master device. This will then enter a database of some kind and will allow a user to browse through their music collection using it’s meta data.
Humans are able to detect even short delays between two audio sources and this is one of the major problems that I am attempting to overcome. There are a number of methods that can be investigated in order to keep the audio in sync but these methods will not be able to completely keep this in sync. Due to the fact that the devices will generally be placed in other rooms, this delay shouldn’t be too noticeable.
Depending on the way that the system will be in contact with the cloud interface (if this route is pursued), there may be a noticeable delay between a user requesting an action on the cloud web interface and the request being actioned on the system.
This code will be released under an Open Source GPL v2 licence. This allows for future improvements and derivatives and use by anyone for free (as in beer).