cidero/doc/html/multiRendererSync.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
   2 <html><head>
   3
   4
   5   <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
   6   <title>Cidero - Home</title>
   7   <link rel="stylesheet" type="text/css" href="multiRendererSync-Dateien/test.css">
   8 </head><body>
   9
  10 <!-- Under construction image at top left -->
  11 <div id="construction" title="construction">
  12 <!--<img src="undercon.gif"/>-->
  13 </div>
  14
  15 <!-- Banner image at top left -->
  16 <div id="banner"><img src="multiRendererSync-Dateien/cideroWebBanner.gif" alt="Banner" align="left">
  17 </div>
  18
  19 <!-- Separator -->
  20 <div id="sep">
  21 <hr style="width: 1000px; height: 4px;">
  22 </div>
  23
  24 <!-- Navigation bar on left -->
  25 <div id="pageNav">
  26 <a href="http://www.cidero.com/index.html">Home</a>
  27 <a href="http://www.cidero.com/downloads.html">Downloads</a>
  28 <a href="http://www.cidero.com/forums/index.php">Forums</a>
  29 <a href="http://www.cidero.com/links.html">Links</a>
  30 </div>
  31 <!-- <a href="contacts.html">Contacts</a> -->
  32
  33 <!-- Page content on right -->
  34 <div id="pageContent">
  35
  36 <h2>Synchronization of Multiple UPnP MediaRenderers</h2>
  37 Synchronization of multiple UPnP renderers is one of the more common
  38 requests from owners of multiple playback devices who want
  39 synchronized, whole-house, audio playback. Unfortunately, the
  40 underlying protocol (HTTP-GET) used by the majority of UPnP servers and
  41 renderers (in the current generation) does not include the necessary
  42 timing information to implement this the 'correct' way. The good news
  43 is that there are well-established protocols that do provide better
  44 support for this (Real-Time Streaming Protocol for example), and UPnP
  45 itself is protocol-agnostic, so in the future this will likely be well
  46 supported by numerous UPnP devices.<p></p>
  47 So...what to do in the interim period before the commonly used UPnP
  48 protocols support 'true' synchronization? One solution for some users
  49 is to use the SlimServer software, since the Slimserver UDP protocol
  50 provides support for synchronization. If one wants to make use of UPnP
  51 HTTP-style servers, though, is there some cheesy synchronization method
  52 that is somewhat usable, if not perfect? Well, <i>maybe</i>, if one is considering only syncing up devices of <b>the same type and firmware release</b>.
  53 The basic idea is to feed the devices from a server that has some
  54 built-in intelligence and attempts to distribute the data to each
  55 renderer in a tightly-controlled, synchronized manner. That can be
  56 'good enough' in some settings. The method relies on the fact that
  57 renderers of the same type have the same end-to-end buffering latency,
  58 so if the packets responsible for 'turning on the device' (the packets
  59 that cause the buffer to be considered full-enough to begin playback)
  60 arrive at the multiple devices at close to the same point in time, the
  61 devices will begin playback close enough togther in time to be
  62 perceived as being synchronized (20-40 milliseconds seems to be a good
  63 goal here). This assumes the renderers have little, if any, timing
  64 'slop' in their primary packet ingest mechanism, such as is introduced
  65 if a polling loop with a sleep of more than 10ms is used rather than an
  66 interrupt-driven (i.e. blocking read) approach. This needs to be
  67 determined on a renderer-by-renderer basis.<br>
  68 <br>
  69 In a favorable network environment (wired or wireless with good signal
  70 quality), this technique can be used with some success. Since none of
  71 the commonly available servers are (yet) capable of this, a 'proxy
  72 server' is required to perform the synchronization. This approach
  73 allows for content from any UPnP server to be played back in a
  74 synchronous manner, with the possible exception of some forms of
  75 DRM-protected content that aren't allowed to pass through a proxy even
  76 if the final destination device is DRM-capable.<br>
  77 <br>
  78 The Cidero software bundle includes a proxy server that works in many
  79 situations&nbsp;(but it should be stressed that your mileage may
  80 vary!). There are
  81 two typical modes of usage. The first mode uses an instance of the
  82 proxy server built in to the controller. This is the default setup when
  83 the software is first installed, since it is the simplest to set up and
  84 use (i.e. run a quick-look test). This setup is illustrated below.<br>
  85 <br>
  86 <br>
  87 <img src="multiRendererSync-Dateien/MultiRendererSyncSetup1.gif" alt="Sync Setup" hspace="10" vspace="10"><br>
  88 <br>
  89 <br>
  90 This is not an optimum configuration since a number of the controller
  91 threads running in the same Java Virtual Machine (JVM) may interfere
  92 with the timing of the proxy thread at the critical 'start of playback'
  93 time. Don't give up on the whole idea prematurely if it doesn't work
  94 very well for you in this configuration!<br>
  95 <br>
  96 The second, preferred, usage is to install an external copy of the
  97 proxy server on the same machine as your primary UPnP media server, or
  98 if using a NAS for a server, another machine on your network that is
  99 hardwired to the network (this assumes that your controller will be
 100 used on a roving wireless laptop, and yes, this does reduce the benefit
 101 of running a NAS - the 'no running PC' benefit). The standalone version
 102 of the proxy server is called 'SyncProxy', with a startup script (.bat
 103 file or .sh file for UNIX) residing in the same place as the
 104 controller's startup script. When using this approach, the proxy
 105 setting for the controller should be modified to reflect the IP address
 106 of the machine on which the proxy is being run. By default, the port is
 107 set to 18081. If this is changed, it needs to be changed in both the
 108 controller UI (don't forget to do a 'File-Save Setup' after making the
 109 change) and in the properties file for the proxy (in <i>$USER_HOME/.cidero/SyncProxy/SyncProxy.properties</i> on the machine in which you are running it). This preferred proxy setup is show in the figure below.<p></p>
 110 <br>
 111 <br>
 112 <img src="multiRendererSync-Dateien/MultiRendererSyncSetup2.gif" alt="Sync Setup" hspace="10" vspace="10"><br>
 113 <br>
 114 <br>
 115
 116 <h3><a name="wmc">Windows Media Connect Users</a><a></a></h3>
 117
 118 <a>WMC requires that all devices accessing it be authorized. It
 119 authorizes by MAC address, so a good general rule of thumb is to run
 120 the controller on the same machine you are installing the proxy on, and
 121 making sure you can browse WMC. Once you authorize the controller, a
 122 proxy running on the same machine should be able to access WMC with no
 123 trouble.<br>
 124 <br>
 125
 126 </a><h3><a name="drift">Inter-Device Timing Drift and Resynchronization</a><a></a></h3>
 127
 128 <a>Even if everything goes well and one achieves perfect
 129 synchronization at the start of playback, two (or more) renderers will
 130 tend to drift with respect to each other over time, due to small
 131 differences in the 'master clock' between devices. Measurements on 2
 132 Roku Soundbridges (an admittedly small sample) found that
 133 for these two devices, after 90 minutes or so, a small echo effect
 134 began to
 135 become noticeable. This situation may be better for some device 'pairs'
 136 and worse for others.<br>
 137 <br>
 138 To deal with the problem, the controller automatically resynchronizes
 139 the stream (stopping and restarting the renderers) periodically, in the
 140 interval between songs. In order to minimize disruption (playback gaps'
 141 within a single album, the synchronization does a simple check to see
 142 if a song is the first song in a series of songs from the same album.
 143 If so, it always resynchronizes at the beginning of the album, so the
 144 album can normally play all the way through with no need to be
 145 resychronized in the middle.<br>
 146 <br>
 147 The resynchronization period and album check logic can be modified for
 148 a particular setup via the 'Options-Synchronization Options'
 149 menu.<br>
 150 <br>
 151 One small optimization that can be used is to figure out which of your
 152 devices plays faster than the others, by temporarily disabling the auto
 153 resync options and letting things run for 4 or 5 hours. If you detect
 154 no echo after that time, you are lucky and you don't have to do
 155 anything! If you do detect an echo, determine which device is 'ahead'
 156 the other. Put the device that runs the fastest in the location that is
 157 usually further away from the majority of listeners. When the devices
 158 first start a playback, there will a small echo effect (may not be
 159 noticeable if systems are within 50' each other) due to the normal
 160 sound propagation delay over the distance between your 2 systems. As
 161 time progresses, this echo should actual be <i>reduced </i>in
 162 the primary listening location if the device in the 'more remote'
 163 location run faster. At some point, of course, the time drift of the
 164 faster device will exceed the normal sound propagation delay, and then
 165 the echo will begin to increase again. Nevertheless, this effectively
 166 doubles the time one can do playbacks without doing a resync, assuming
 167 there are no (or infrequent) listeners at the remote, secondary
 168 location. Hey, I <i>said</i>it was cheesy!<br>
 169 <br>
 170
 171
 172 </a><h3><a>Trying it out</a></h3>
 173
 174 <a>Ok, too much low-level information probably! Trying it out in the
 175 default configuration is reasonably simple. Bring up the renderer
 176 windows for 2 devices. Slave one of the renderers to the other using
 177 the 'link' button at the bottom right of the transport control panel.
 178 Add some content to the play queue, and hit Play as you normally would.
 179 If sync is lousy the first time, try it at least once more before
 180 giving up.<br>
 181 <br>
 182 After that, I highly recommend configuring and running the proxy server
 183 on the same machine as your default media server (hopefully a hardwired
 184 machine). That generally improves the sync performance quite a bit, as
 185 does having the renderers themselves hardwired as opposed to wireless.
 186 Use the 'Options-Synchronization Options' dialog to configure the
 187 controller to use a remote proxy (remember to do a 'File-Save Setup' if
 188 you want to make the change permanent). Then simple run the 'SyncProxy'
 189 on the machine with the IP address you specified in the controller
 190 window<br>
 191 <br>
 192 Have fun with it - I hope it works for ya!<br>
 193 <br>
 194 <br>
 195  Feedback always welcome.<br>
 196 <br>
 197
 198 </a></div>
 199
 200 </body></html>