Managing multiroom audio with Linn Songcast and upmpdcli

Multiple Songcast Receiver hosts can connect to the same Sender, so that they will all be playing the same audio. They form a group only in the sense that they play from the same URI, and are not otherwise linked.

The Mac and Windows Songcast apps only let you activate one Receiver though.

The upmpdcli package now includes the scctl command line utility, which can list the state of the local Songcast Receivers, make a Receiver play from the same URI as another one (for building multi-room groups), or return a Media Renderer from Receiver to normal operation.

As the Songcast application is only available on Windows or Mac desktops, it would be inconvenient to have to access the Linux command line to control the multi-room groups, and the upmpdcli package also includes a small Web application which can be accessed from a desktop web browser to control the groups.

This has only be tested with upmpdcli and its sc2mpd Songcast auxiliary process as Receiver implementation, but I’d guess that there is a good chance it would work with others.

The short version is: all sc2mpd instances must be configured to play directly to Alsa. See the configuration section.

Longer version: Songcast is a real-time audio stream. As the Sender and Receiver sample clocks (the 44.1 or 48 KHz clocks) are independant, audio reproduction on the two systems will slowly drift. If nothing is done, after a time, the Receiver will have to skip samples or add a period of silence (depending if its clock is slower or faster), which is quite audible and ennoying, and will happen "from time to time", depending of how much the clocks differ.

The only way to control this is to adjust the rate of reproduction on the Receiver, which can be done in two ways:

This is not specific to Songcast of course, all real time audio network transports have to do something similar.

Independantly of the clock issue, all Receivers should use approximately the same amount of buffering for the audio to be reasonably synchronous (with no more shifts than moving around would produce anyway). This is impossible to achieve when going through mpd, and the second reason why sc2mpd must be set in alsa mode for multiroom setups. In mpd mode, the Receivers can be out of sync by several seconds.

Once the slave Receivers are associated with the Sender, they should stay in this state until you change it. So you can stop/start Songcast on the PC, and they will usually just follow.

An "associated" Receiver is just one which plays from the same URI, it keeps no other relation to the "Master". Only one Receiver is a bit special because it is the one known from the PC, but there is no specific reason to use it as Master, the Master is only used to get the URI. Avoid changing the state of the "PC"'s Receiver from outside the PC Songcast interface, this can only confuse things.

To avoid having to access the command line interface to control the Songcast groups, upmpdcli comes with a small Web server which uses scctl to actually do the work. This is found inside the web/ subdirectory inside the upmpdcli source tree.

The server is based on the Bottle Python Web Framework and it only depends on Python (version 2 and 3 are supported by Bottle, but the current app only works with Python 2).

You can use the scweb-standalone.py script to manually start the interface:

This will start a server on localhost, on port 8680 by default which is good for testing, but not very useful. Use the -a 0.0.0.0 option to let the server answer on all local addresses (or specify the address to use a specific interface):

-p can be used to specify a port.

Once started, connecting to the server from any browser should hopefully display a reasonably self-explanatory interface.

Recent upmpdcli packages install the web app as a service named scweb. The service is not started by default though, you need to edit /etc/default/scweb.