Bug 4677 - Cannot synchronize Transporter with SB3 using built-in Ogg playback
: Cannot synchronize Transporter with SB3 using built-in Ogg playback
Status: RESOLVED WONTFIX
Product: SB 2/3
Classification: Unclassified
Component: Audio
: unspecified
: All SuSE Linux
: P2 minor (vote)
: Future
Assigned To: Unassigned bug - please assign me!
:
Depends on: 6442
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-17 08:29 UTC by Keith Briscoe
Modified: 2010-05-07 10:56 UTC (History)
4 users (show)

See Also:
Category: ---


Attachments
Log for Bug 4677 (54.96 KB, text/plain)
2007-01-30 14:53 UTC, Spies Steven
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Keith Briscoe 2007-01-17 08:29:33 UTC
The built-in Ogg decoder for the SB3 starts playback a fraction of a second later than playback on the Transporter.  This means that it is impossible to synchronize Ogg playback on an SB3 and Transporter using the built-in decoder.

A fraction of a second may not sound like much, but trust me, it's enough to drive you crazy.

Workaround: disable native playback in SlimServer, transcoding to another format which synchronizes okay.
Comment 1 Spies Steven 2007-01-19 10:07:26 UTC
Keith, are you experiencing the delay with all tracks in the play list or just the first one? In other words if you let it play through the first few tracks does it sync up again?
Comment 2 Keith Briscoe 2007-01-19 13:03:35 UTC
It happens throughout the playlist, and it doesn't get any better or worse over time.  The delay appears to be a fixed value.  It only happens for Ogg files--FLAC files are fine.
Comment 3 Keith Briscoe 2007-01-19 13:12:57 UTC
I'm using firmware 27 on the Transporter and firmware 72 on the SB3, if it matters.
Comment 4 Spies Steven 2007-01-19 14:27:13 UTC
Keith, how do you have your players networked & what hardware are you using? Wired? Wireless? Also please paste your version info from the sever settings page in your reply.
Comment 5 Keith Briscoe 2007-01-19 17:29:26 UTC
Here's a dump of a lot of information that may or may not be helpful in reproducing the problem:

Server:
Pentium 4 2.26 GHz running SuSE Linux 10.1
SlimServer Version: 6.5.1 - 11206 - Linux - EN - iso-8859-1
Server IP address: 192.168.1.72
Perl Version: 5.8.8 i586-linux-thread-multi
MySQL Version: 5.0.21-standard

Transporter:
Wired, 100mbit, firmware 27

Squeezebox:
Wireless, 802.11g-only, channel 1, WPA2-AES, Wireless Signal Strength: as low as 71% and as high as 83% (per SlimServer), firmware 72

WAP:
Buffalo WHR-G54S, with DD-WRT firmware v23 SP2

I hope you can reproduce the problem on your end.  I imagine that because FLAC synchronizes fine, you could probably repro even if both devices use a wired connection.  My SB3 is wall-mounted, so I'd rather not test mine on a wired connection unless there's no other option.
Comment 6 Spies Steven 2007-01-22 09:50:28 UTC
Keith, thank you for the additional info. Hopefully I will be able to reproduce.
Comment 7 Spies Steven 2007-01-22 15:46:16 UTC
I am able to reproduce the behavior.

Playing a series of Ogg Vorbis files while synced between a Transporter and a SB3 produces between .25 and .33 second difference. I tried both wired, both wireless and one wired one wireless with out any noticeable difference.

I also tried syncing with two SB3s and had the same problem however the delay was shorter at around .17 to .15 second.
Forcing Ogg Vorbis to transcode to another format allowed syncing without noticeable delay.

Richard, should this be assigned to you?
Comment 8 Andy Grundman 2007-01-23 09:47:04 UTC
Steven: Can you make a --d_source --d_sync --d_playlist log file?
Comment 9 Spies Steven 2007-01-30 14:53:08 UTC
Created attachment 1798 [details]
Log for Bug 4677

Log with d_playlist, d_server, d_source and d_sync enabled.
Comment 10 Richard Titmuss 2007-02-08 02:47:25 UTC
I've had a quick look at the log but don't see anything unusual, Andy what are your thoughts? Ogg files have a longer startup delay than other formats, I wonder if this is causing the players to autostart before the slimserver tells the players to start.
Comment 11 Spies Steven 2007-09-14 16:14:46 UTC
This issue appears to be fixed with Alan's recent changes to syncing in SlimServer 7.  Thanks Alan!  More information can be found here: http://forums.slimdevices.com/showthread.php?t=38054&highlight=sync
Comment 12 Keith Briscoe 2007-10-08 13:27:34 UTC
Excellent news!  Just to confirm, the newest version of SS7 available for public download should include this fix and I should be able to verify on my system, correct?
Comment 13 Spies Steven 2007-10-08 13:44:37 UTC
That is correct. Just be sure to do a firmware update. I believe firmware 82 for Squeezebox and firmware 32 for Transporter or higher is required for this to work properly. Feedback on how it worked for you would be appreciated.
Comment 14 Keith Briscoe 2007-10-10 13:15:46 UTC
Verified the issue is fixed on the 10/9/2007 nightly.  Hooray!

Getting the SlimServer init working properly took more work than usual on SuSE, but was doable.  I'm assuming init scripts are the last bits to make ready for prime-time though, so I didn't want to file a bug unless you think it's a good idea.
Comment 15 Chris Owens 2007-10-11 10:50:58 UTC
Since there was not a change specifically to fix this bug, I am marking it resolved as 'WORKSFORME'
Comment 16 Keith Briscoe 2008-03-04 13:49:57 UTC
This bug still exists in the released version of SqueezeCenter 7/firmwares.  I believe my earlier test results saying this bug was fixed were incorrect--the behavior has merely changed slightly.

The track start on a Transporter is still a fraction of a second earlier than the track start on an SP3, probably off by the same amount as before.  The difference is that within a couple of seconds, the new SC7 sync code kicks in and the tracks become synchronized and stay synchronized.  So in order to see this bug, you will now need to use a track that has sharp clear sounds in the first second or so.
Comment 17 Chris Owens 2008-03-04 17:15:59 UTC
Steven, could you have another look at this to see if it's reproducible?  I can generate test data if you're having a hard time finding something suitable.
Comment 18 Andy Grundman 2008-03-05 16:55:38 UTC
Un-targeting and referencing bug 6442 which is the root cause of this issue.
Comment 19 Spies Steven 2008-03-19 15:18:29 UTC
Just like Keith points out that the ogg does indeed start out of sync but immediately gets corrected by the new sync function.  I'm confident that once bug 6442 is resolved that this issue will go away.  Assigning to unassigned for now.
Comment 20 Alan Young 2010-05-07 10:56:55 UTC
All new Squeezebox products are likely to be based on the SqueezePlay platform.
We do not plan to implement any further enhancements to the ip3k firmware or
which are targeted specifically at ip3k-based products.