PDA

View Full Version : How do things go out of sync?



jaffacake
2008-05-07, 06:22
I'm trying to understand the sync process and how it works.

I see options in the SqueezeCenter settings that allow me to configure how far my playback is allowed to get out of sync before it attempts a re-sync and how often it should do this. I get this part.

When 2 or more players are synced, there is a slight delay before playback commences. The units pre-buffer the music data in the chosen codec and then are all instructed to start playback at the same time. For the purposes of the discussion, we'll say they all start at the time time, 0ms.

All the players are playing from the same source, the same bit and bytes. They're in the same codec and go through the same decoder. The end result should be exactly the same, for lossless codecs you'd expect the decoded output to be exactly the same as the original CD.

So I'm trying to understand how 2 adjacent players can become out of sync when playing back an identical source at the same time. The only way, that I can figure out, is if one of them was playing at a different speed to the other. It would either be faster, and skip ahead...or slower and lag behind.

But with an accurate playback, how can this be?

So I understand why they need to be synced before playback commences. I understand a re-sync might be necessary if a player is added or removed from the group. What I don't get is how that sync can be lost at a later point in time. Surely 23456ms after they start playback, they should all be 23.456seconds into the track? Why would this not be the case?

Can anybody explain?

bpa
2008-05-07, 06:26
This is a good thread on the work that was done to Synch to improve it for SC7 and the issues addressed.

http://forums.slimdevices.com/showthread.php?t=34535

MuckleEck
2008-05-07, 06:29
BEn,

Are you trying to sync two Squeezeboxes/receivers or are you using softsqueeze as well?

jaffacake
2008-05-07, 06:32
BEn,

Are you trying to sync two Squeezeboxes/receivers or are you using softsqueeze as well?

I've been trying with softsqueeze too.

I know if i start 2 CD players at the same time they will stay in sync until the end of the track and they aren't even linked.. I'm wondering why this setup is different.

jaffacake
2008-05-07, 06:36
This is a good thread on the work that was done to Synch to improve it for SC7 and the issues addressed.

http://forums.slimdevices.com/showthread.php?t=34535

Thanks. I read the first post and I read


The real work was on maintaining synchronization. With long tracks, and especially streaming from Internet radio and the like, synchronization can drift over time. Also, other sporadic events can cause a player to pause for a moment. So I set about trying to measure the drift with a view to being able to correct it.

The OP is taking the sync drift as assumed and working around it. My query is why/how it happens in the fist place, if we're assuming a local source and no buffer underrun.

andyg
2008-05-07, 06:37
Softsqueeze is hit or miss, there are many layers between the hardware and the player that can introduce delay. With hardware players it should be perfect, except for WMA radio stations.

andyg
2008-05-07, 06:38
Sync drift happens because the clocks in different players tick at very slightly different rates. You'll only drift after many minutes, this is why long-running radio stations always got out of sync before 7.0.

jaffacake
2008-05-07, 06:38
Softsqueeze is hit or miss, there are many layers between the hardware and the player that can introduce delay. With hardware players it should be perfect, except for WMA radio stations.

It should be perfect or it is perfect?

If it is perfect, why do I have resync configuration settings?

jaffacake
2008-05-07, 06:41
Sync drift happens because the clocks in different players tick at very slightly different rates. You'll only drift after many minutes, this is why long-running radio stations always got out of sync before 7.0.

So does that mean that one player will play faster than the other and be slightly different from the original source?

Would the clock be more accurate in, for example, Transporter hardware where owners might expect a more accurate reproduction of the source?

andyg
2008-05-07, 06:41
It should be perfect with the default settings. Those settings are for tweaking in case you have something like a DAC that introduces extra delay, or for tweaking delay to get a Softsqueeze player to sync properly.

jaffacake
2008-05-07, 06:58
andyg - Thanks for the responses, much appreciated.

seanadams
2008-05-07, 10:22
So does that mean that one player will play faster than the other and be slightly different from the original source?

Would the clock be more accurate in, for example, Transporter hardware where owners might expect a more accurate reproduction of the source?

The crystals in SB3 are specified to within 50ppm accuracy, so if you take the worst case where one is fast by 50ppm and the other is slow by 50ppm, then you have a total drift between the two of 100ppm or 0.000100. After one hour, the faster player would be ahead by 0.000100 hours == 360 milliseconds, which is easily audible. In reality I don't think you would ever find crystals as bad as that, but it's easy to see how even at +/- 10ppm, correction for clock drift is still required. I would estimate the threshold of audibility for the casual listener to be about 50ms.

As an approximate rule of thumb 1ms is equal to 1 foot at the speed of sound. Typically there is some distance between the two rooms so you would add that to the drift that is perceived.

Certainly Transporter has a better clock but it is hard to estimate exactly by how much two Transporters might drift slower than two squeezeboxes. It's a manufacturing tolerance issue so you can't really characterize it without comparing LOTS of units. In any case, a design which depends on two crystals having exactly the same frequency is simply broken as this is never achievable in practice. Even two perfectly identically manufactured crystals will not behave the same in a real world setting because they will be operating at different temperatures, and this affects the speed too.

I am not entirely up to speed on all of the improvements that Alan has made but my most recent understanding is that we still resync on track boundaries. This is not an unreasonable approach, but it's not ideal either because it inherently makes it difficult to do gapless playback while synced. To do that we would need to implement a gradual correction scheme where clock drift is corrected over a relatively long period of time.

jaffacake
2008-05-07, 12:30
seanadams,

Thanks a lot, I really appreciate the time you've spent on this reply.

nwplace
2008-05-08, 15:08
The crystals in SB3 are specified to within 50ppm accuracy, so if you take the worst case where one is fast by 50ppm and the other is slow by 50ppm, then you have a total drift between the two of 100ppm or 0.000100. After one hour, the faster player would be ahead by 0.000100 hours == 360 milliseconds, which is easily audible. In reality I don't think you would ever find crystals as bad as that, but it's easy to see how even at +/- 10ppm, correction for clock drift is still required. I would estimate the threshold of audibility for the casual listener to be about 50ms.

As an approximate rule of thumb 1ms is equal to 1 foot at the speed of sound. Typically there is some distance between the two rooms so you would add that to the drift that is perceived.

Certainly Transporter has a better clock but it is hard to estimate exactly by how much two Transporters might drift slower than two squeezeboxes. It's a manufacturing tolerance issue so you can't really characterize it without comparing LOTS of units. In any case, a design which depends on two crystals having exactly the same frequency is simply broken as this is never achievable in practice. Even two perfectly identically manufactured crystals will not behave the same in a real world setting because they will be operating at different temperatures, and this affects the speed too.

I am not entirely up to speed on all of the improvements that Alan has made but my most recent understanding is that we still resync on track boundaries. This is not an unreasonable approach, but it's not ideal either because it inherently makes it difficult to do gapless playback while synced. To do that we would need to implement a gradual correction scheme where clock drift is corrected over a relatively long period of time.

I have sync problems with SC7.0 and the suggestion in my case is that this may be due the drift of the clock of the hardware that sc7.0 is installed on, in which case the accuracy of the SB3 crystal is irrelevant to a certain extent?

I have to stress that the analysis of my problem is not complete, however, the implication here is synchronisation is a function of the players only??

awy
2008-05-12, 23:50
As Sean says, assuming units remain within specified tolerances, maximum theoretical drift between a pair of SB3s is 300ms/hr == 6 ms/min. For two sets of speakers in different rooms, 50ms may be a good estimate of the maximum acceptable error. Our common listening case is somewhere approximately half way between two sets of speakers, in which case I think that 30ms tends to be about the maximum acceptable error, which could occur within 5 minutes and will very likely occur within half an hour, listening to internet radio or the like.

But 6ms/min is for SB3s. SC will also sync with SB1s (not so well) and SliMP3s, and also with software players such as SoftSqueeze and Squeezeslave. I suspect (but don't actually know) that the older hardware may not have such well-specified crystals. And, in any case, software players are generally dependent on the crystal of the computer's sound card: I have observed drift rates of worse than 1ms/s (== 60ms/min) with such cards.

Finally, as you noted in you original post, SC attempts to get all players to start at the same time. Sometimes, problems with network latency (more likely with wireless networks) or within the computer running SC, may mean that they do not all get the start command in time, in which case post-start adjustment is necessary (there are other techniques which can be used here and there are good reasons why the current technique is used).

I hope this helps.
Alan.