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 trac
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 sometim
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 s
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
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
---
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) that
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 Profi
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
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.
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 t
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 t
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 'bytes
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
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
-
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
amclu
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 t
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 hom
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
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 simila
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.
To make sure that I am starting in the right place, let me briefly
assert my understanding of how the curren
20 matches
Mail list logo