Bugzilla – Bug 6666
synchronisation offset when unpausing if player has volume set to 0
Last modified: 2008-12-18 11:12:53 UTC
If a player has volume set to 0 and other players have volume set to a non 0 value, sychronisation offset can occur when unpausing. Volume set to 0 often used for people using digital output as it suppresses the annoying fade/in out.. Easy fix is to reintroduce the volume fade when sychronised - I'll do this, but Alan you may want to look at this case again.
change 16480 seems to resolve
Had to revert the patch, it at least broke synced players that have different volumes.
I do not understand why fading in, or its absence, should have any effect on the sync offset. It is the case that no attempt is made to produce synchronized resume semantics. After a resume it is quite likely that the players are not in sync and will need to be resynced.
hopefully change 16493 does what I was originally intending - only delaying the callback, not altering the actual volume Please review. Alan - the issue I found was that for players with volume set to 0 (using digital out with fixed volume on this), then the volume fade does not occur. This means that pause/unpause occurs more quicking introducing a startup offset in the streams which is very noticable. Normally they resync after a while, but the intial offset is very noticable to the point where it sounds broken. I'm not sure if this offset is 0.3 or 0.6 seconds (1 or 2 fade durations) but we need to avoid it... So this patch introduces the delay before calling the callback for such cases even though the volume will be set to 0 straight away.
Is this resolved now?
I hope so, but it would be good if Alan could review.
I am afraid that I still do not see how the original problem could arise, at least not such that this change will fix it. When pausing, a callback is used (Source::pauseSynced) so that only after the master player has completed its fade-out, regardless of the current fade state of the other players in the sync-group, all the players are instructed to pause. (It might be keyed to the master player, or an arbitrary player in the sync-group, depending upon how Source::playmode($client, "pause") is invoked but I do not think that this is relevant.) When unpausing, all players are resumed, with fade-in (obviously) starting after they start playing. No callback is used upon fade-in completion. Your change ensures that the callback from fade-out completion will occur at a predictable time, even if the master (or designated) player has volume == 0. But even if this callback is fired immediately, while other players were still doing their fade-out, they all get told to pause at the same time. The remaining fade-out still happens but the players will already be paused. As I mentioned earlier, it is the case, upon resume, that no attempt is made to ensure a synchronized resume. It would be possible to take into account the actual play position of each player and used unpauseAt() to ensure a synchronized resume, but this is not done.
Triode, can you reply to Alan so we can finish this up? Thx!
I don't have time to review the code again in detail until next weekend, but I definately observed a significant offset between the two streams on unpause which is removed with this patch. What seemed to happen is that the streams would normally resync, but this would take a second or so and so there is a startup period when it sounded districtly odd. Test case is: - transporter, volume = 0, fixed digital out into external dac - ray, volume set to non 0 value with analog output In all cases pressing play or fwd/rew results in streams which start synchronised. Pressing pause/unpause causes the streams to start unsynched and then come into sync after a second or so. This was much improved with the patch, so I assumed it was due to each player actually pausing at a different point. Need to review all of the code for this though. In the mean time can anyone see a downside to my latest patch, I tried to make it so it would not do anything other than delay the callback.
No, I don't see a downside. It will allow a player that needs-to/can fade-out to do so even if the master has vol==0.
I think that I have got to the bottom of what is going on here. Sync-maintenance continues even while paused. Fix coming.
Change 16657 The real problem was that the sync-maint code also ran while paused. Generally not a problem, because it is only triggered by incoming status packets, and these are infrequent while paused and are ignored when more than a second or so old. But, with some player(s) continuing to fade-out after paused (when the master has volume==0) the ACKs for the volume commands (audg packets) triggered the adjustment. Of course, this only had an effect after the resume, when it immediately need to be corrected!
Not able to test until the weekend, but do we need to remove my patch then Alan? [can't see a downside to leaving it, but if you have fixed it for this case then may want to remove?]
No, like I said, leaving your patch in still has some useful consequences.
This bug is being closed since it was resolved for a version which is now released! Please download the new version of SqueezeCenter (formerly SlimServer) at http://www.slimdevices.com/su_downloads.html If you are still seeing this bug, please re-open it and we will consider it for a future release.