|
a/doc/scmulti.txt |
|
b/doc/scmulti.txt |
| 1 |
= Managing multiroom audio with Linn Songcast and upmpdcli
|
1 |
= Managing multiroom audio with Linn Songcast and upmpdcli
|
| 2 |
|
2 |
|
| 3 |
== What is Linn Songcast
|
3 |
General information about *upmpdcli* support for *Songcast* can be found
|
| 4 |
|
4 |
link:sc2mpd.html[here]. This page explains how to set up a multiroom
|
| 5 |
*Songcast* is a protocol for transporting audio streams across the network,
|
5 |
synchronized audio system using *upmpdcli* and *Songcast*.
|
| 6 |
developped by link:http://oss.linn.co.uk/trac/wiki/Songcast[Linn] as a
|
|
|
| 7 |
series of open-source libraries and applications.
|
|
|
| 8 |
|
|
|
| 9 |
There are two types of entities involved in the protocol:
|
|
|
| 10 |
|
|
|
| 11 |
- A *Songcast* _Sender_ generates an audio stream.
|
|
|
| 12 |
- A *Songcast* _Receiver_, which typically runs on an OpenHome Renderer,
|
|
|
| 13 |
receives the stream and plays it.
|
|
|
| 14 |
|
|
|
| 15 |
The streams transported by *Songcast* are actual real-time audio data, which
|
|
|
| 16 |
can go straight to an audio card for playing.
|
|
|
| 17 |
|
|
|
| 18 |
Controlling the streams (connecting, starting, stopping) is
|
|
|
| 19 |
done through an UPnP service named OpenHome __Receiver__, which runs on an
|
|
|
| 20 |
UPnP Media Renderer implementing the OpenHome services.
|
|
|
| 21 |
|
|
|
| 22 |
The typical use of *Songcast* is to have an audio driver on a Windows or OS X
|
|
|
| 23 |
desktop capture and forward the audio stream to a remote *Songcast* device
|
|
|
| 24 |
(this is the main purpose of the *Songcast* Mac and Windows applications,
|
|
|
| 25 |
apart from actually controlling the audio destination).
|
|
|
| 26 |
|
|
|
| 27 |
Any application on the desktop will (be compelled to) transparently play to
|
|
|
| 28 |
the remote device, without need to know anything about *Songcast*.
|
|
|
| 29 |
|
6 |
|
| 30 |
== Multiple Receivers
|
7 |
== Multiple Receivers
|
| 31 |
|
8 |
|
| 32 |
Multiple _Receiver_ hosts can connect to the same _Sender_, so that they
|
9 |
Multiple *Songcast* _Receiver_ hosts can connect to the same _Sender_, so
|
| 33 |
will all be playing the same audio.
|
10 |
that they will all be playing the same audio.
|
| 34 |
|
11 |
|
| 35 |
The Mac and Windows *Songcast* apps only let you connect the _Sender_ to one
|
12 |
The Mac and Windows *Songcast* apps only let you activate one
|
| 36 |
Receiver though.
|
13 |
_Receiver_ though.
|
| 37 |
|
14 |
|
| 38 |
*upmpdcli* now includes a small application which can list the state of
|
15 |
*upmpdcli* now includes a small application which can list the state of
|
| 39 |
the local *Songcast* Receivers, make a Receiver play from the same URI as
|
16 |
the local *Songcast* Receivers, make a Receiver play from the same URI as
|
| 40 |
another one (for building multiroom groups), or return a Media Renderer
|
17 |
another one (for building multiroom groups), or return a Media Renderer
|
| 41 |
from Receiver to normal operation.
|
18 |
from Receiver to normal operation.
|
|
... |
|
... |
| 47 |
|
24 |
|
| 48 |
This has only be tested with *upmpdcli* and its link:sc2mpd.html[sc2mpd]
|
25 |
This has only be tested with *upmpdcli* and its link:sc2mpd.html[sc2mpd]
|
| 49 |
*Songcast* auxiliary process as Receiver implementation, but I'd guess that
|
26 |
*Songcast* auxiliary process as Receiver implementation, but I'd guess that
|
| 50 |
there is a good chance it would work with others.
|
27 |
there is a good chance it would work with others.
|
| 51 |
|
28 |
|
| 52 |
This is very preliminary for now and there are a number of issues, I hope
|
29 |
== Synchronisation issues
|
| 53 |
to improve them, but for now, this is definitely an _early adopters_ system:
|
|
|
| 54 |
|
30 |
|
| 55 |
- The initial synchronisation when forming the group is very bad. To
|
31 |
The short version is: all sc2mpd instances must be configured to play
|
| 56 |
resynchronize everything, stop or pause the playing on the PC (from the
|
32 |
directly to Alsa. See the link:sc2mpd.html#Configuration[configuration
|
| 57 |
player, e.g. Media Player, not from the Songcast utility), wait for the
|
33 |
section].
|
| 58 |
audio to drain, and a few seconds more, then restart playing.
|
|
|
| 59 |
- Receivers slowly drift out of sync, especially if they use different
|
|
|
| 60 |
hardware. I intend to work on this, but it's a difficult issue.
|
|
|
| 61 |
- It's quite easy to put the system in a confused state where nothing
|
|
|
| 62 |
seems to work any more. Stopping all Receivers (with *scctl* or the Web
|
|
|
| 63 |
interface) and restarting the PC will normally get things back to
|
|
|
| 64 |
sanity, but it will sometimes be necessary to restart everything.
|
|
|
| 65 |
*Always give the commands a little time to take effect*. Especially,
|
|
|
| 66 |
it's quite common that the audio will not begin to play for around
|
|
|
| 67 |
10 S after activation from the *Songcast* PC interface. Clicking on
|
|
|
| 68 |
stuff too early is the surest way to get into bad states, always give
|
|
|
| 69 |
10 S to the system when things seem to not be happening.
|
|
|
| 70 |
|
34 |
|
| 71 |
- _The following problem seems to be gone from the latest *Songcast*
|
35 |
Longer version: Songcast is a real-time audio stream. As the Sender and
|
| 72 |
code_ (which is used by the current `ohbuild.sh` script). Songcast can
|
36 |
Receiver sample clocks (the 44.1 or 48 KHz clocks) are independant, audio
|
| 73 |
be transported by either unicast or multicast IP. multicast is of
|
37 |
reproduction on the two systems will slowly drift. If nothing is done,
|
| 74 |
course much better for the network load, but I seem to have seen random
|
38 |
after a time, the Receiver will have to skip samples or add a period of
|
| 75 |
*sc2mpd* crashes with it. I am not sure of the cause (may be not linked
|
39 |
silence (depending if its clock is slower or faster), which is quite
|
| 76 |
to multicast at all), but if you experience random *sc2mpd* crashes,
|
40 |
audible and ennoying, and will happen "from time to time", depending of how
|
| 77 |
switch *Songcast* to unicast (in the PC Songcast app advanced
|
41 |
much the clocks differ.
|
| 78 |
configuration panel. Unicast is the default).
|
42 |
|
|
|
43 |
The only way to control this is to adjust the rate of reproduction on the
|
|
|
44 |
Receiver, which can be done in two ways:
|
|
|
45 |
|
|
|
46 |
- Linn hardware uses timestamps embedded in the audio stream to adjust
|
|
|
47 |
their hardware sample clock.
|
|
|
48 |
- sc2mpd in Alsa mode uses sample rate conversion to adjust the stream.
|
|
|
49 |
|
|
|
50 |
This is not specific to Songcast of course, all real time audio network
|
|
|
51 |
transports have to do something similar.
|
|
|
52 |
|
|
|
53 |
Independantly of the clock issue, all Receivers should use approximately
|
|
|
54 |
the same amount of buffering for the audio to be reasonably synchronous
|
|
|
55 |
(with no more shifts than moving around would produce anyway). This is
|
|
|
56 |
impossible to achieve when going through mpd, and the second reason why
|
|
|
57 |
sc2mpd must be set in Alsa mode for multiroom setups. In mpd mode, the
|
|
|
58 |
receivers can be out of sync by several seconds.
|
| 79 |
|
59 |
|
| 80 |
|
60 |
|
| 81 |
== Setting things up
|
61 |
== Setting things up
|
| 82 |
|
62 |
|
| 83 |
The following seems to work for me:
|
63 |
- Install upmpdcli and sc2mpd on each of the _Receiver_ systems. Edit
|
|
|
64 |
`/etc/upmpdcli.conf` to set:
|
|
|
65 |
* `friendlyname`, this is quite useful when managing several systems.
|
|
|
66 |
* `scplaymethod` = alsa
|
|
|
67 |
* `scalsadevice`: use `aplay -L` to chose an appropriate device.
|
| 84 |
|
68 |
|
| 85 |
- Remove libupnpp and upmpdcli packages from the system to avoid confusion
|
69 |
- Activate the web interface on one of the Receivers (or on any machine
|
| 86 |
- Clone the libupnpp, upmpdcli and sc2mpd repositories from
|
70 |
with upmpdcli installed actually). Edit `/etc/default/scweb` to
|
| 87 |
link:https://github.com/[GitHub]
|
71 |
configure the interface (see comments in there) and start it with
|
| 88 |
- Follow the usual procedure to build. This should just be the usual for
|
72 |
`/etc/init.d/scweb-service start`.
|
| 89 |
libupnpp and upmpdcli:
|
|
|
| 90 |
|
|
|
| 91 |
sh autogen.sh
|
|
|
| 92 |
./configure --prefix=/usr
|
|
|
| 93 |
make
|
|
|
| 94 |
sudo make install
|
|
|
| 95 |
|
73 |
|
| 96 |
- For sc2mpd, things are a small bit more complicated, see the _Building
|
|
|
| 97 |
sc2mpd_ section in link:sc2mpd.html[this document].
|
|
|
| 98 |
- Repeat the above steps on all the machines which you want to be Receivers.
|
|
|
| 99 |
- Activate a Receiver from the PC *Songcast* interface. Play something and
|
74 |
- Activate a Receiver from the PC *Songcast* interface. Play something and
|
| 100 |
leave it playing.
|
75 |
leave it playing.
|
| 101 |
- Use either *scctl* (`scctl -h` prints a simple help message), or the Web
|
76 |
|
| 102 |
interface (see further) to associate other Receivers to the same Sender.
|
77 |
- Connect to the Web interface (host and port chosen above) with a
|
| 103 |
- Stop or Pause the music. Wait 10 S, restart. *_Multiroom !_*
|
78 |
browser, and use it to list, activate, or disconnect the Receivers.
|
| 104 |
|
79 |
|
| 105 |
Once the slave Receivers are associated with the Sender, they should stay
|
80 |
Once the slave Receivers are associated with the Sender, they should stay
|
| 106 |
in this state until you change it. So you can stop/start Songcast on the
|
81 |
in this state until you change it. So you can stop/start Songcast on the
|
| 107 |
PC, and they will usually just follow.
|
82 |
PC, and they will usually just follow.
|
| 108 |
|
83 |
|
| 109 |
An "associated" Receiver is just one which plays from the same URI, it
|
84 |
An "associated" Receiver is just one which plays from the same URI, it
|
| 110 |
keeps no other relation to the "Master". Only one Receiver is a bit special
|
85 |
keeps no other relation to the "Master". Only one Receiver is a bit special
|
| 111 |
because it is the one known from the PC, but there is no specific reason to
|
86 |
because it is the one known from the PC, but there is no specific reason to
|
| 112 |
use it as Master, the Master is only used to get the URI. Avoid changing
|
87 |
use it as Master, the Master is only used to get the URI. Avoid changing
|
| 113 |
the state of the "PC"l Receiver from outside the PC *Songcast* interface,
|
88 |
the state of the "PC"'s Receiver from outside the PC *Songcast* interface,
|
| 114 |
this can only confuse things.
|
89 |
this can only confuse things.
|
| 115 |
|
90 |
|
| 116 |
Every time you change the group configuration, you need to resynchronize
|
91 |
== More detail about the Web interface
|
| 117 |
the audio by pausing, waiting, restarting.
|
|
|
| 118 |
|
|
|
| 119 |
I do know that the whole thing is not very solid, this is a prototype and I
|
|
|
| 120 |
hope to improve some of the issues in the future: constructive problem
|
|
|
| 121 |
reports are more than welcome, but no flaming (for now) please :)
|
|
|
| 122 |
|
|
|
| 123 |
|
|
|
| 124 |
== Controlling the Songcast groups from the Web interface
|
|
|
| 125 |
|
92 |
|
| 126 |
To avoid having to access the command line interface to control the
|
93 |
To avoid having to access the command line interface to control the
|
| 127 |
*Songcast* groups, *upmpdcli* comes with a small Web server which uses
|
94 |
*Songcast* groups, *upmpdcli* comes with a small Web server which uses
|
| 128 |
*scctl* to actually do the work. This is found inside the `web/`
|
95 |
*scctl* to actually do the work. This is found inside the `web/`
|
| 129 |
subdirectory inside the *upmpdcli* source tree.
|
96 |
subdirectory inside the *upmpdcli* source tree.
|
|
... |
|
... |
| 131 |
The server is based on the
|
98 |
The server is based on the
|
| 132 |
link:http://bottlepy.org/docs/dev/index.html[Bottle Python Web Framework]
|
99 |
link:http://bottlepy.org/docs/dev/index.html[Bottle Python Web Framework]
|
| 133 |
and it only depends on Python (version 2 and 3 are supported by *Bottle*,
|
100 |
and it only depends on Python (version 2 and 3 are supported by *Bottle*,
|
| 134 |
but the current app only works with Python 2).
|
101 |
but the current app only works with Python 2).
|
| 135 |
|
102 |
|
| 136 |
I'll find ways to autostart the server in the future, but for now,
|
|
|
| 137 |
use the `scweb-standalone.py` script to manually start it:
|
103 |
You can use the `scweb-standalone.py` script to manually start the
|
|
|
104 |
interface:
|
| 138 |
|
105 |
|
| 139 |
python2 ./scweb-standalone.py
|
106 |
python2 ./scweb-standalone.py
|
| 140 |
|
107 |
|
| 141 |
This will start a server on localhost, on port 8777 which is good for
|
108 |
This will start a server on localhost, on port 8780 by default which is
|
| 142 |
testing, but not very useful. Use the -a 0.0.0.0 option to let the server
|
109 |
good for testing, but not very useful. Use the -a 0.0.0.0 option to let the
|
| 143 |
answer on all local addresses (or specify the address to use a specific
|
110 |
server answer on all local addresses (or specify the address to use a
|
| 144 |
interface):
|
111 |
specific interface):
|
| 145 |
|
112 |
|
| 146 |
python2 ./scweb-standalone.py -a 0.0.0.0
|
113 |
python2 ./scweb-standalone.py -a 0.0.0.0
|
| 147 |
|
114 |
|
| 148 |
-p can be used to specify a port.
|
115 |
-p can be used to specify a port.
|
| 149 |
|
116 |
|