Generally it works quite well, and the interface to sync/unsync is good.
However, sync has a number of issues which prevent it from being as
1st-class as the rest of the system - so, thanks very much for working
to improve it!
A few comments about things that could be better:
1) gapless + sync
I have 2 SB3s in different (yet quite close) rooms, both running
wirelessly (from 6.5.1 SS on Linux FC5). When synced for music (usual
stuff - album tracks 3-5 minutes each), I haven't noticed a problem. I
frequently use AlienBBC to Listen Again to (UK) BBC Radio 4 shows
though, and I do
bukharin;197654 Wrote:
- fast forwarding/rewinding when players are sync'd is not usable
- syncing a player to a player which is already playing something
should just join in rather than forcing the other player to start the
current track again. This sounds petty but it's not when tracks
I'm synching two players, and I'd like to adjust the time delay between
them to minimize echo. Is there some way like a plugin or hidden player
setting to do this?
I'm currently synching an SB3 and a computer running SoftSqueeze 3.3.
All files are lossless (flac), and I have high-quality digital
The problem with a set delay is that there's going to be a variance in
the amount of network delay each time the players sync up at the start
of each track. This is even worse for wireless networks.
--
andyg
andyg's
For what it's worth, here is my experience with synchronization.
In general, things actually work very very well. I do have two
problems, however:
1) The current sync implementation breaks gapless playback and inserts
a very audible gap between consecutive tracks. I understand (and
agree)
I usually sync between 8 and 10 players, all wired, and do not have any
problems with drifting except on Internet Radio streams. I do have a
problem where the playlist will get stuck between songs when players
are synced. It never happens with a single independent player.
--
upstatemike
CatBus;197588 Wrote:
2) Syncing between SB3 and Transporter doesn't work with native Ogg
playback, so I have to transcode to FLAC. Not a big deal in itself
(and an easy enough workaround), but this may indicate a problem in how
the basic sync process currently works, because the sync
My work on improving the synchronization system is progressing. I'd like
some feedback from people who use synchronization regularly as to what
actual problems they have. Also, people who have tried to use it and
found it inadequate for their purposes your feedback would be good
too.
I'd like
I'm glad you're working on this, because sync was a major attraction in
deciding to go with SD, but it has always been a roll of the dice for
me. I have two wired SB2s and a wireless SB3, although the sync
problems show up even if I connect the SB3 via ethernet. Sometimes the
sync is fine, other
I have two SB2s permanently synced. One in the living room and one in
the kitchen. I have others but all used independently.
The two synced SB2s are wired and play mainly flac and occasional MP3
albums. The server is Windows XP box with 2.5GHZ processor and 500MB
memory and doing not much else.
So which of the above tends to be the real cause of the problem? I guess
that (3) could be tackled by forcing a re-sync whenever an under-run is
detected.
Does (2) happen? If so, what are the clock tolerances on the different
devices?
--
awy
Hmm, 10-20ms, perhaps it is doable.
I realise that both getting the initial sync precise and then
maintaining it would best be done with firmware support. I suspect that
firmware change may be needed in the end but here is an outline of how
it could possibly be done without it.
On my LAN at
A couple of simple firmware enhancements could possibly be helpful.
- Have each ACK include the player's 1kHz clock tick value
- Have a -start-playing (unpause) at clock-tick value- command
- Have a -pause for N clock-ticks- command
Using the mechanism described in the previous message
Given the the speed of sound in air is 345 m/s, even a 10m separation of
Squeezeboxes (one upstairs, one downstairs) would result in the distant
sound being delayed ~29ms to someone at the local player.
--
amcluesent
Each time you send a 'stat' request to the player
($client-requestStatus), you do get back the player's tick value in ms
since last reboot (jiffies). See
Slim::Networking::Slimproto::_stat_handler. stat is called once per
second while the player is playing.
--
andyg
awy wrote:
Hello,
I'm giving some serious thought about how to improve the multi-player
synchronization problem. In particular, the issue that players can get
out of synchronization with each other.
Good, there's room for improvement.
To make sure that I am starting in the right place,
I guess that I have been concentrating on the SliMP3 protocol (as I only
have SliMP3s, no SBs).
Reading Slim::Networking::Slimproto I see that the stat response seems
to include loads of good stuff. How accurate is the 'elapsed_seconds'
measure (presumably only integral seconds) and is the
Yes you've touched on all the right issues.
The most delay the human ear will tolerate is something like 10-20ms I
believe.
What needs to happen in order to have better syncing is to use a synced
clock with millisecond-resolution on all players and the server, using
NTP, SNTP or something
19 matches
Mail list logo
