Bugzilla – Bug 259
Synchronization should use fine-grained network clock
Last modified: 2008-12-22 23:07:17 UTC
I am running SlimServer 5.1.1 on Windows XP with three wireless Squeezeboxes all of which have had the 5.1.1 firmware upgrade. When I synchronise two of them I do not appear to have a problem. When I synchronise three of them after 1/2 hour or so I will fine that one of them (often the last one synchronised, but not always) will drift one second or so out of sync.
comment from bug793 by barkarus@earthlink.net (Baron Nealy) Team - the syncronization between devices and Squeezeboxes is inconsistant. There are times it works well but over time while listening the sync is lost - the result is an extremely prominent echo. I have read that SlimDevices plans to add a network clock - this needs to be done as a priority since the product touts "whole house audio." The product is promising in most areas but this needs to be addressed sooner than later.
I've added Baron's comments here because 793's report seems to be two distinct issues, the first of which matches up better with this report.
Vidur, is this still an issue?
*** Bug 793 has been marked as a duplicate of this bug. ***
*** Bug 1697 has been marked as a duplicate of this bug. ***
I've been reminded of this bug and I'm still keen to get a resolution. It occurs to me that solving this needs work on the server and the firmware. Unfortunately this means the fix can only be done by slimdevices. Is there any way we can request a quote for this development work? I'd be prepared to pay some to bump this. Malcolm
Am writing here because I assume anything I mention about players getting out of sync will be marked a duplicate of this. I have 2 SB2 devices networked to the same server over 11g wireless. The router is a D-link DI-524 with ANT24 (7dB gain) antenna (the SB2s have standard antenna). One player is in our bedroom, which is the room right next to the wireless router (3 metres tops between antennas), the other is in the lounge, a whole 10-12 metres or so away, but even so, the lounge player will have problems occasionally (I notice particularly when I use the microwave in the kitchen between the two). Signal strength seems OK in the lounge as is shown here: < 10 : 0 : 0% < 20 : 0 : 0% < 30 : 0 : 0% < 40 : 0 : 0% < 50 : 35 : 1% < 60 : 122 : 4% ## < 70 : 2088 : 75% ##################################### < 80 : 545 : 20% ######### < 90 : 0 : 0% < 100 : 0 : 0% >=100 : 0 : 0% max : 75.000000 min : 41.000000 avg : 65.513262 Anyhow, usually the two will work fine on their own, but have extreame problems playing in sync. My guess is that I've read the SB2 will start playing once the buffer fills with a set length of a track. Given that the bedroom is closer, that will have a faster network connection and it's buffer will fill sooner, while the lounge can sometimes only barely keep up with 'real time' streaming. This is with lossless FLAC, BTW. Shouldn't sync work by having the server feed each SB's buffer and then determine when they should play by sending a control signal only when the server is happy with the buffer level in each (all)? On the subject of radio and sync, shouldn't the server collect a remote radio stream only once, and then distribute to SBs on the local LAN, with sync signals every now and then to make sure things are in check? It appears that when one has 2 SBs listening to the same station, each connects to that station's source which is terribly bandwidth hogging.
Subject: Re: Synchronization should use fine-grained network clock Robin: That's exactly how it works now, a start command is sent once each player's buffer is full enough. Also, when slimserver is sending a radio station to multiple players in sync it only opens up one connection. If they aren't in sync, it does open two. -dean
(In reply to comment #8) > Subject: Re: Synchronization should use fine-grained network clock > > Robin: That's exactly how it works now, a start command is sent once > each player's buffer is full enough. Sorry, I don't buy this. Of if that is how it's _supposed_ to work, it's broken here (SlimServer Version: 6.3.0 - 8154 - Linux - EN - utf8 Player Firmware Version: 55). They players are sync'd. Set the 'now playing' to display buffer fullness. Hit next... instant change, buffer fullness creeps slowly to 100% in the lounge (see my previous post). Doing this in the bedroom is the same story, except fullness rockets up. Clearly the players are not buffering anywhere near enough before starting. How much are they meant to? This is with lossless FLAC so of course one should be measuring the duration buffered, not bytes (MP3s will of course need less then). In very bad network environments like mine one should be able to tune fullness, perhaps per-player (ie. I don't want the lounge to start playing until it's 100% full, but the bedroom is fast enough to start after 50%). Perhaps some network bandwidth measurements should be make as things stream and the server decide buffering automagically? How does it send music to 2 players simultaneously? Using broadcast packets? Or packet 1->player 1, packet 1->player 2, packet 2->player 1, packet 2->player 2, etc? Seems broadcast is what should happen, but don't think that is happening.
*** Bug 598 has been marked as a duplicate of this bug. ***
See http://forums.slimdevices.com/showthread.php?t=34535 for a description of work and approach I have been doing on this problem. My approach will not solve all the sync issues but I think that it is a good start.
I am voting for this bug and also would like to see synchronization become gapless to eliminate the annoying gaps in playing live recordings.
Alan's patch has been merged to trunk. This one needs a lot of testing, so get to it! :)
(In reply to Andy Grundman, comment #13) > Alan's patch has been merged to trunk. This one needs a lot of testing, so get to it! :) I'd be happy to test the new version. Where can I download it? Oren
www.slimdevices.com/downloads/nightly/latest/7.0
Alan, is there any reason to keep this bug open anymore, or is it solved to your satisfaction?
yes, I think that it is fixed now. All the test reports have been good.
As I understand it, this still doesn't fix the issues with gapless playback on sync'd players. What is the situation there?
Gapless (and cross-fade) are not supported with sync. If fact the default setting with these changes may even make gapless a little worse (but more consistent). It will be considered for a future enhancement but is lower on the priority list than mid-stream join.
This bug appears to have been fixed in the latest release! If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look. Make sure to include the version number of the software you are seeing the error with.
Before I try the latest code (I'm running on a QNAP 101 so its a considerable hassle) can someone please confirm that this is genuinely fixed (including gapless playback)? If not then can we please reopen the bug?
Yes, it s fixed, including gapless (but not gapless for SliMP3s and SB1s).
I'm using 7.3 and sync four players. A transporter, two squeezebox3's and one Squeezebox2. My server is an IMAC on 10.4. Do I understand it correctly in that we are now supposed to have full gapless playback when synching multiple players? So on a live album there will be no gaps between songs. We are now supposed to have completely smooth transitions in tracks that are supposed to flow together (this is so irritating to listen to)? If that's what this bug is saying to be resolved in 7.3 I would like to report that it hasn't for me. I have had some tracks play seamlessly but most do not. My playlists are freezing at the end of songs. The gaps are there and they have been much worse with a host of other problems since I upgraded from 6.5. I bought a controller that caused me to upgrade. I haven't even turned the controller on in two weeks because I don't want to make the host of other problems worse. I guess I should stick to the main topic and not go into a rash of other things that I've had to deal with. Perfect, seemless gapless playback with multiple players synched has been the single most irritating thing to me in using Slim products over the years. It's to bad that we're still not there yet. If it's something that I'm missing please let me know. I'm no tech expert just somebody who loves music. Is it just me that is having this problem with gapless sync on multiple boxes with 7.3? Everyone else says it's working great consistently and bug closed?
It sounds like you have had and are having a horrible time with this. Let me see if I can find the cause of your problems. And yes, synchronized, gapless play of 4 players should work just fine. What kind of music files are you playing: flac, mp3, ...? I you play on a single player then do they play gapless without a problem? When you have non-gapless play (when synced) is this reproducible with a particular pair of tracks? When you say "My playlists are freezing at the end of songs" do you mean that manual intervention is necessary to get things going again? Do you know what the load is like on your IMAC? Are you able to observe peaks when tracks change and if so what is the size and duration of such peaks? Are your players all connected over a wireless network or are some or all of them wired? If wireless then what kind (802.11b or 802.11g)? From the Settings / Information page, what is the reported Wireless Signal Strength for each wirelessly connected player. How is your IMAC connected to the network? I have some suggestions for some logging output to collect. If you could enable two logging settings via the page Settings / Advanced / Logging. Set player.source to the value 'info' and 'network.protocol.slimproto' and then press the Apply button. Please make a note of the exact time and the tracks for which you get a bad transition and include this information with the logfile (the filename of which is shown at the top of the Settings / Advanced / Logging page). Please add the logfile as an attachment to this bug. I hope we can find out what it is that is not working for you.
I've done a quick search of the forums and it seems that people are indeed happy this is fixed in version 7.3 but would it be possible for someone to explain how exactly it has been fixed? I can think of 3 possibilities: 1) Re-syncing is still done by inserting silence between tracks but it is not done between every track only when it is safe to do so (e.g. between albums). I'm guessing its not this one because with crossfade you would never get a chance to re-sync. 2) Re-syncing is done constantly by dropping or duplicating individual samples. I'm guessing this is the most likely. 3) Re-syncing is done constantly by adjusting the DAC clocks of the individual players. I'm not sure if the hardware is actually capable of this.
Thanks for the reply Alan, I notice that the bug is listed as closed/resolved. Is that something that I should change or is this something that only Slim/Logitech does? I'll go through each af your parragraphs as if they were numbered. 1)-I'm playing all Apple Lossless tracks and have my settings to use Itunes. 2)-I play a single player for two hours to go to sleep every night and haven't had the problem. 3)-I don't think that I could say that it was any two particular songs that won't do gapless. I could maybe try to test this out but I get the feeling that it would do gapless maybe one out of three times on any given group of tracks. Every once in a while things will run smoothly. It's a problem that may not happen for a few songs but will then be almost constant. I seem to be following the pattern now. The song will end. If I'm looking at the player display it will first say rebuffering......then it will say waiting to sync.... Sometimes it will say rebuffering failed. This may be when things stop and intervention is necessary, I'll have to try to keep an eye on that. If I'm looking at squeezecenter when the next song is refusing to play the next song will be in display constantly replaying the first few seconds of the song over and over again with no sound from any room. I've been trying to notice any patterns of when the problems occur in the last few days. There are definitely less problems if I listen to a long playlist (hours) without interruption. If I play a few songs and then pause things for a while there are almost always problems in getting the rest of the playlist to play properly. 4)-Yes this is the problem, generally the problems fall into a few different categories that I tried to start to detail in the paragraph above. One of the things that commonly happens is that the next song on the playlist won't play. This can happen in a way different to what is described above. I won't see the rebuffering and waiting to sync but the next song will just not start playing. Usually if I go into the playlist and press play the song will start playing. I will try to start checking in squeezecenter if the first few seconds of the song are looping as described above. This can happen during most of the songs in a playlist one time and another time I can play several albums without it happening. The fix is to go into now playing and manually press play for the problem song. 5)-Not being a technical person this isn't really something I'm good at doing. I just opened system monitor and watched the cpu usage for ten minutes or so. It showed 80-90% idle. I checked it through three song transitions on a live cd. Of course because I was sitting there waiting all three transitions were absolutely perfect. Of course I had to manually play the transition ten minutes before that because it was completely stuck. I also had the song before that get hung up and after several seconds it played the same song over again so I had to straighten that out. I take it the process for the music is mysqld? I didn't see anything peaking during the transitions. 6)-When I first filled out this bug and for the past year all four players have been wireless. Yesterday I wired the one room that it is physically cable of being wired. After wiring the player the next song immediately froze up. It's been good and bad since then. As soon as I think it's getting much better it gives me several problems. My router is the newer Airport Express g. When I fist set it up I had a host of problems and through Slim customer service we set it up for b/g networks. I copied the players signal strengths from when all four were wired and now that it's three: -Version: 7.3 - 24282 @ Thu Dec 11 14:14:14 PST 2008 Server HTTP Port Number: 9000 Operating system: Mac OS X 10.4.11 (8S2167) - EN - utf8 Platform Architecture: x86 Perl Version: 5.8.6 - darwin-thread-multi-2level MySQL Version: 5.0.22-standard Total Players Recognized: 4 Library Statistics Total Tracks: 41,991 Total Albums: 3,132 Total Artists: 1,462 Total Genres: 22 Total Playing Time: 3094:03:48 10.0.1.196 BR Player Model: squeezebox2 Firmware: 120 Player IP Address: 10.0.1.196 Player MAC Address: 00:04:20:05:bc:ee Wireless Signal Strength: 70% 10.0.1.197 TR Player Model: transporter Firmware: 70 Player IP Address: 10.0.1.197 Player MAC Address: 00:04:20:10:02:30 Wireless Signal Strength: 99% Voltage: 118 10.0.1.198 K Player Model: squeezebox3 Firmware: 120 Player IP Address: 10.0.1.198 Player MAC Address: 00:04:20:06:c3:6f Wireless Signal Strength: 98% 10.0.1.200 LR Player Model: squeezebox3 Firmware: 120 Player IP Address: 10.0.1.200 Player MAC Address: 00:04:20:06:ef:2a Wireless Signal Strength: 87% ..............Three wireless and one wired: 10.0.1.196 BR Player Model: squeezebox2 Firmware: 120 Player IP Address: 10.0.1.196 Player MAC Address: 00:04:20:05:bc:ee Wireless Signal Strength: 64% 10.0.1.197 TR Player Model: transporter Firmware: 70 Player IP Address: 10.0.1.197 Player MAC Address: 00:04:20:10:02:30 Wireless Signal Strength: 97% Voltage: 115 10.0.1.198 K Player Model: squeezebox3 Firmware: 120 Player IP Address: 10.0.1.198 Player MAC Address: 00:04:20:06:c3:6f Wireless Signal Strength: 87% 10.0.1.200 LR Player Model: squeezebox3 Firmware: 120 Player IP Address: 10.0.1.200 Player MAC Address: 00:04:20:06:ef:2a Wireless Signal Strength: 84 Total Tracks: 41,872 Total Albums: 3,124 Total Artists: 1,442 Total Genres: 21 Total Playing Time: 3086:51:00 7) I managed to find and enable the logs. I then played a concert cd with 20 short songs/transitions and of course it played almost perfectly because I was watching. It did have one very short pause with a quick rescan/resync but nowhere near as bad as it's been. I then looked at the log and this stuff is just way over my head. I had no idea what I was looking at or where to find the pause. I don't know if we're going to get very far having me check out logs.
Hi, I have opened a new bug 10426 to track your specific problem as I think that this bug is, in general, fixed under most circumstances.
I think that the coffee has not yet kicked in. The new one is bug 10436 (not as mentioned in the previous comment)