Bugzilla – Bug 6864
SB1 synch problems
Last modified: 2009-09-08 09:21:20 UTC
Synchronized play of internet radio sometimes seems worse on 7.0 than with 6.5. Initially, on a fresh reboot of the server, the players will stick together, usually for about half an hour. At some point one player (it seems to happen with one Squeezebox V1 more than others, but not always and unpredictably) winds up ahead of the other three players. At that point, it begins skipping ahead as if it thinks it's behind, trys to catch up, but is simply getting further and further ahead and out of synch. The other players seem to stay in synch pretty well but over time they will exhibit some skipping. Stopping the stream, turning some of the players off, and starting it up again on just a couple of players and the skipping usually stops and the remaining players stay happily synched. 7.0 will keep all four players in perfect synch playing FLACs for hours at a time. But if I try to play synchronized FLACs off my local hard drive after the skipping internet streaming behavior described above, the FLACs are often out of synch and skip. So I wind up killing and restarting the SqueezeCenter or just rebooting the whole system and all's well. Simply turning all the players off then turning them all back on doesn't solve the problem. I've swapped some of the players around and it doesn't appear to be a problem with one specific Squeezebox, nor with a specific cable run. This problem only arises when at least on SB1 is in the mix. I don't know what format SqueezeCenter is using to transcode FLACs (WAV or MP3) when both SB1s and SB3s are playing in synch. I have not changed the defaults. As suggested, I changed the logging settings for player.synch to debug and will figure out where to post the file that resulted after reproducing this behavior. The timeline was rougnly: 29 January 2008 I rebooted the system at 0800, at 1730 listened to WHYY's streaming audio for a a while. All players were fully synched for about a half hour. Around 1800, the streaming audio fell out of synch and at least one of the SB1s started skipping and jumping. At 1815 or so, I played the first five tracks of The Beatles 1 and each track was out of synch and skipping on various players, both SB1s and SB3s. Setup: SqueezeCenter Version: 7.0 - 16791 - Debian - EN - utf8 Server IP address: 192.168.0.4 Perl Version: 5.8.8 i486-linux-gnu-thread-multi MySQL Version: 5.0.45-Debian_1ubuntu3.1 I've increased the Synchronized Players Startup Delay from 100ms to 200ms; this had no noticable effect on playing FLACs, but streaming audio over the Internet is more likely to start our in synch. This is running on Ubuntu 7.10 server on an AMD Athlon XP 2800+, 160GB FD, 512MB RAM. Since all it runs is SAMBA and SqueezeCenter, I chose the Ubuntu server edition to minimize the overhead on the system: no GUI, and I dropped the system memory used by the video card from 128MB to 8MB. I manage the system via Telnet from behind my NAT box. Two Squeezebox V1s, two Squeezebox 3s, all hard wired.
Created attachment 2773 [details] logfile described in text when behavior was reproduced This logfile is enormous.
Alan: any idea?
Here is a forum message on this subject. Including it here just for the context as some of the questions are answered in the report already. http://forums.slimdevices.com/showpost.php?p=263240&postcount=37 My guess is the problem is the SB1s. In terms of maintaining synchronization, this is the hardest case - SliMP3s are actually better. And I must admit that I have done less testing with SB1s that with other player types. I would certainly not rule out a logic bug in this case. Do you always have both SB1s in the sync-group when the problems arise? Basically, sync works best with SB2-and-above player types - these have specific protocol support for sync management. If you add just one SliMP3 or SB1 to the mix, then the algorithms will always use the more-capable adjustment mechanisms of the newer players. But once you have two or more of either SliMP3 or SB1s, then more-primitive adjustment mechanisms sometimes have to be used, and these are particularly hit-and-miss with SB1s. I have not done any testing with two SB1s in the mix. When you play local FLAC files, these will have to be transcoded to a common format supported by both SB1s and SB3s (assuming that you have both in the sync-group). Do you know if your configuration is using WAV or MP3 in this case? I admit that I have done no testing of sync when WAV is being streamed. But, in any case, I presume that for Internet radio streams, these are in MP3 and so will not be locally transcoded. The fact that the problem persists with local tracks after first loosing sync on a radio stream is particularly interesting. If you were able to reproduce this with logging set to player.sync=debug and then open a bug (bugs.slimdevices.com) for this, attaching the log along with a commentary of what happened when, this would be useful.
Phil: There are a couple of questions in Alan's last comment: Do you always have both SB1s in the sync-group when the problems arise? Do you know if your configuration is using WAV or MP3 in this case? We'd like to understand this better.
(In reply to comment #4) > Phil: There are a couple of questions in Alan's last comment: > Do you always have both SB1s in the sync-group when the problems arise? > Do you know if your configuration is using WAV or MP3 in this case? > We'd like to understand this better. Yes, both SB1s are in the sync-group when this happens. I haven't been able to reproduce this with just on SB1 on a fresh reboot of the system. Once it starts, I can drop to just one SB1 and the behavior continues. I don't know if the system is transcoding to WAV or MP3. It's a default, vanilla installation. If you can tell me where to look, I'm happy to let you know. Thanks.
From the log it looks like wav is being used for the local files, and possibly with an error in the settings: Use of uninitialized value in hash element at /usr/share/perl5/Slim/Player/Squeezebox.pm line 1164 I think that it s using mp3 without transcoding for the radio station but I'm not completely sure.
It is clear that sync-groups with multiple SB1s will not generally work well. However it does seem that something else is going on here. Will continue to investigate but not for SC7.0. An option in this case if you want SB1s to start in sync but be ignored with regard to keeping them in sync during a track is to set the player preference maintainSync (Settings / Players / <player> / Audio / Maintain Synchronization) to "Don't maintain synchronization"
(In reply to comment #7) > It is clear that sync-groups with multiple SB1s will not generally work well. > However it does seem that something else is going on here. Will continue to > investigate but not for SC7.0. > An option in this case if you want SB1s to start in sync but be ignored with > regard to keeping them in sync during a track is to set the player preference > maintainSync (Settings / Players / <player> / Audio / Maintain Synchronization) > to "Don't maintain synchronization" Over the weekend I had time to fiddle with the server settings and forced all the players to transcode to MP3 (same 320kbps bitrate and quality for all players). Streaming audio from the internet still exhibits the same behavior with players getting further and further out of synch (not surprising, the change shouldn't affect that), local tracks synch noticably better, even after the players have gotten confused on streaming audio. They are much more likely to start play in synch and stay pretty close if not in lock step, even without having to reboot the server. Phil
Change 17285 (on trunk, not 7.0 branch) stops trying to do micro-adjustments for SB1s. It seems that the SB1 hardware cannot reliably pause and resume without losing a frame or two to resynchronization in the decoder. The completely messes up SC's idea of the play-point (how much of a track has been played at what point in time) because some data has been consumed by the player but was not played. The result is that each time SC tries to pause an SB1 for a few ms, to get it back into line with the other players in the sync-group, it most likely actually gets further ahead, from SC's point of view. The consequence of this is that sync-groups containing multiple SB1s (or a single SB1 and one or more SliMP3s) will not stay in sync. Other players in the sync-group will still adjust and so a sync-group with just one SB1 should be fine. Sync groups with multiple SliMP3s and no SB1s should also still be fine (although lots of synced SliMP3s starts chewing up the server CPU). Also fine should be sync-groups with one SB1 and any number of SB2/SB3/TP/SBRs. You can still build sync-groups with multiple SB1s but they may not stay in sync and cannot be adjusted if they don't start up in sync. Note that you still (probably) want to leave the player preference maintainSync (Settings / Players / <player> / Audio / Maintain Synchronization) set to "Maintain synchronization". This way SC will do the best it can. If you set it to "Don't maintain synchronization" then the SB1s won't even be considered in the sync-maintenance algorithm. Alan.
There was a typo in change 17285 which has been fixed in change 17971.