--- a/doc/scmulti.html
+++ b/doc/scmulti.html
@@ -745,23 +745,35 @@
<div class="paragraph"><p>General information about <strong>upmpdcli</strong> support for <strong>Songcast</strong> can be found
<a href="sc2mpd.html">here</a>. This page explains how to set up a multiroom
synchronized audio system using <strong>upmpdcli</strong> and <strong>Songcast</strong>.</p></div>
+<div class="admonitionblock">
+<table><tr>
+<td class="icon">
+<div class="title">Note</div>
+</td>
+<td class="content">multicast and WIFI don’t mix well in many cases. If you have
+wireless Receivers experiencing sound drop issues, try selecting unicast in
+the Songcast advanced configuration panel on the desktop.</td>
+</tr></table>
+</div>
</div>
</div>
<div class="sect1">
<h2 id="_multiple_receivers">Multiple Receivers</h2>
<div class="sectionbody">
<div class="paragraph"><p>Multiple <strong>Songcast</strong> <em>Receiver</em> hosts can connect to the same <em>Sender</em>, so
-that they will all be playing the same audio.</p></div>
+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.</p></div>
<div class="paragraph"><p>The Mac and Windows <strong>Songcast</strong> apps only let you activate one
<em>Receiver</em> though.</p></div>
-<div class="paragraph"><p><strong>upmpdcli</strong> now includes a small application which can list the state of
-the local <strong>Songcast</strong> Receivers, make a Receiver play from the same URI as
-another one (for building multiroom groups), or return a Media Renderer
-from Receiver to normal operation.</p></div>
-<div class="paragraph"><p>The functions can be accessed either from the <strong>scctl</strong> command line utility,
-or from a local Web application (as Songcast is mostly used from a Windows
-or Mac PC, it would be inconvenient to have to access the Linux command
-line to control the multiroom groups).</p></div>
+<div class="paragraph"><p>The <strong>upmpdcli</strong> package now includes the <strong>scctl</strong> command line utility, which
+can list the state of the local <strong>Songcast</strong> <em>Receivers</em>, make a <em>Receiver</em>
+play from the same URI as another one (for building multi-room groups), or
+return a <em>Media Renderer</em> from <em>Receiver</em> to normal operation.</p></div>
+<div class="paragraph"><p>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 <strong>upmpdcli</strong> package also includes a
+small Web application which can be accessed from a desktop web browser to
+control the groups.</p></div>
<div class="paragraph"><p>This has only be tested with <strong>upmpdcli</strong> and its <a href="sc2mpd.html">sc2mpd</a>
<strong>Songcast</strong> auxiliary process as Receiver implementation, but I’d guess that
there is a good chance it would work with others.</p></div>
@@ -770,39 +782,39 @@
<div class="sect1">
<h2 id="_synchronisation_issues">Synchronisation issues</h2>
<div class="sectionbody">
-<div class="paragraph"><p>The short version is: all sc2mpd instances must be configured to play
+<div class="paragraph"><p>The short version is: all <strong>sc2mpd</strong> instances must be configured to play
directly to Alsa. See the <a href="sc2mpd.html#Configuration">configuration
section</a>.</p></div>
-<div class="paragraph"><p>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
+<div class="paragraph"><p>Longer version: <strong>Songcast</strong> is a real-time audio stream. As the <em>Sender</em> and
+<em>Receiver</em> 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
+after a time, the <em>Receiver</em> 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.</p></div>
<div class="paragraph"><p>The only way to control this is to adjust the rate of reproduction on the
-Receiver, which can be done in two ways:</p></div>
+<em>Receiver</em>, which can be done in two ways:</p></div>
<div class="ulist"><ul>
<li>
<p>
-Linn hardware uses timestamps embedded in the audio stream to adjust
+<strong>Linn</strong> hardware uses timestamps embedded in the audio stream to adjust
their hardware sample clock.
</p>
</li>
<li>
<p>
-sc2mpd in Alsa mode uses sample rate conversion to adjust the stream.
+<strong>sc2mpd</strong> in <em><tt>alsa</tt></em> mode uses sample rate conversion to adjust the stream.
</p>
</li>
</ul></div>
-<div class="paragraph"><p>This is not specific to Songcast of course, all real time audio network
+<div class="paragraph"><p>This is not specific to <strong>Songcast</strong> of course, all real time audio network
transports have to do something similar.</p></div>
-<div class="paragraph"><p>Independantly of the clock issue, all Receivers should use approximately
+<div class="paragraph"><p>Independantly of the clock issue, all <em>Receivers</em> 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.</p></div>
+<strong>sc2mpd</strong> must be set in <em><tt>alsa</tt></em> mode for multiroom setups. In <em><tt>mpd</tt></em>
+mode, the <em>Receivers</em> can be out of sync by several seconds.</p></div>
</div>
</div>
<div class="sect1">
@@ -822,7 +834,7 @@
</li>
<li>
<p>
-<tt>scplaymethod</tt> = alsa
+<tt>scplaymethod</tt> = <em><tt>alsa</tt></em>
</p>
</li>
<li>
@@ -834,33 +846,33 @@
</li>
<li>
<p>
-Activate the web interface on one of the Receivers (or on any machine
+Activate the web interface on one of the <em>Receivers</em> (or on any machine
with upmpdcli installed actually). Edit <tt>/etc/default/scweb</tt> to
configure the interface (see comments in there) and start it with
- <tt>/etc/init.d/scweb-service start</tt>.
+ <tt>service scweb start</tt>.
</p>
</li>
<li>
<p>
-Activate a Receiver from the PC <strong>Songcast</strong> interface. Play something and
+Activate a <em>Receiver</em> from the PC <strong>Songcast</strong> interface. Play something and
leave it playing.
</p>
</li>
<li>
<p>
Connect to the Web interface (host and port chosen above) with a
- browser, and use it to list, activate, or disconnect the Receivers.
+ browser, and use it to list, activate, or disconnect the <em>Receivers</em>.
</p>
</li>
</ul></div>
-<div class="paragraph"><p>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
+<div class="paragraph"><p>Once the slave <em>Receivers</em> are associated with the <em>Sender</em>, they should stay
+in this state until you change it. So you can stop/start <strong>Songcast</strong> on the
PC, and they will usually just follow.</p></div>
-<div class="paragraph"><p>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
+<div class="paragraph"><p>An "associated" <em>Receiver</em> is just one which plays from the same URI, it
+keeps no other relation to the "Master". Only one <em>Receiver</em> 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 <strong>Songcast</strong> interface,
+the state of the "PC"'s <em>Receiver</em> from outside the PC <strong>Songcast</strong> interface,
this can only confuse things.</p></div>
</div>
</div>
@@ -881,7 +893,7 @@
<div class="content">
<pre><tt>python2 ./scweb-standalone.py</tt></pre>
</div></div>
-<div class="paragraph"><p>This will start a server on localhost, on port 8780 by default which is
+<div class="paragraph"><p>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></div>
@@ -892,13 +904,16 @@
<div class="paragraph"><p>-p can be used to specify a port.</p></div>
<div class="paragraph"><p>Once started, connecting to the server from any browser should hopefully
display a reasonably self-explanatory interface.</p></div>
+<div class="paragraph"><p>Recent <strong>upmpdcli</strong> packages install the web app as a service named
+<strong>scweb</strong>. The service is not started by default though, you need to edit
+<tt>/etc/default/scweb</tt>.</p></div>
</div>
</div>
</div>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2015-05-06 10:18:31 CEST
+Last updated 2015-05-19 16:15:38 CEST
</div>
</div>
</body>