The following preferences affect the operation of the synchronization
algorithms (defaults in parenthesis):
*syncPower* (0): Should turning the power of one player in a sync-group
on or off effect the other players in the group?
*syncVolume* (0): Should changing the volume of one player in a
sync-group effect the other players in the group?
*syncBufferThreshold* (bytes: 128, SLIMP3=15000): How much audio data
must be buffered by the player before the server will start
synchronized play across a sync-group. This needs to be sufficient so
that short-term network congestion, which can be more severe with
wireless networks, does not result in an under-run condition (the
player runs out of data) shortly after starting.
*maintainSync* (1): Should the server attempt to maintain
synchronization for this player by tracking the point at which it is
playing and making (usually small) adjustments for discrepancies with
respect to other players in the sync-group.
*minSyncAdjust* (seconds: minimum=0.010, maximum=10.000, default=0.030,
SB2-and-on=0.010): the minimum discrepancy between this player and
another player before the server will attempt to adjust the play-point
of this player.
*packetLatency* (seconds: 0.002): The time between the player sending a
status message to the server and the server receiving the status.
Generally the server will calculate this dynamically but there may be
some cases where it is helpful to set a longer default.
*startDelay* (seconds: 0): How long after the player receives the
start-playing command, will audio actually start playing. This may need
to be non-zero if digital outputs are being used (depends upon the
downstream component) or with software players (SoftSqueeze, etc.).
*playDelay* (seconds), -not yet implemented:- How much audio is
actually delayed compared to what a player reports has been played.
This may need to be non-zero if digital outputs are being used (depends
upon the downstream component) or with software players (SoftSqueeze,
etc., depending of the platform, drivers, sound-card, etc.).
*syncStartDelay* (seconds: 0.010): Once all players in the sync-group
are deemed to be ready to play (see *syncBufferThreshold*) then a
command is sent to each one indicating a point in time in the future
when they should start playing. This preference indicates how far in
the future, from the time the server sends the commands, that the
players should start. This preference value should be large-enough so
that the command can (usually) be received by all players within the
specified period, even in the face of short-term network congestion
which is more common with wireless networks.
All these preferences, with the exception of *syncStartDelay* are
player-specific (that is, player preferences).
Mostly there is no web-UI for these. You need to use the command-line
interface to manage them (clearly this is not acceptable longer term).
_Diagnosing_problems_with_synchronization._
Use log-level 'debug' for 'player.sync'.
- Players often, but not always, have to be resynchronized
immediately after starting to play a track. It is likely that
*syncStartDelay* needs to be increased (suggest upper limit 0.250).
This is most-likely to be the case if it is observed that it is not
always the same player that is resynchronized.
- A player starts to play then stops and then starts again; the
display may briefly say 'Resynchronizing' or 'Paused'. Adjusting the
*syncBufferThreshold* may help.
- A player is (nearly) always resynchronized immediately after
starting to play a track. If the player is using digital outputs, or
is a software player (SoftSqueeze, squeezeslave), then it is possible
that there is a fixed start-up delay and this can be compensated for
using *startDelay*.
- A pair or set of players are frequently being resynchronized,
playing catch-up with one-another. Older players (SliMP3, original
Squeezebox) and software players (depending of the specific platform,
drivers and sound cards) may report inconsistent play points, in which
case increasing *minSyncAdjust* may help.
- The server thinks that a pair of players are properly synchronized
but they do not sound right. It could be that a constant delay is
being introduced by downstream components from the player (hardware
or software). This should not be the case when using analogue outputs
from a hardware player (SliMP3, Squeezebox, Squeezebox2/3,
Transporter) but could occur with digital outputs or with software
players. It has been reported to occur with SoftSqueeze under
Microsoft Windows and it has been observed that it mostly does not
occur under Linux. If it happens then the knob to turn is
*playDelay*, although one will have to use one's ears to work out how
much.
All changes to these preferences should take effect immediately.
--
awy
------------------------------------------------------------------------
awy's Profile: http://forums.slimdevices.com/member.php?userid=7480
View this thread: http://forums.slimdevices.com/showthread.php?t=38054
_______________________________________________
beta mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/beta
