View Full Version : First attempt at synchronized playback -> disaster!

2007-01-15, 20:04
I have two players: a Transporter and a SB3. The Transporter is wired (100 MBit) and the Squeezebox is wireless (802.11g, very good signal strength, not shared with any other devices).

I tried to sync them for the first time today, and the result was horrifying. There was a full second delay (and growing) between the players, only seconds into playback. Skipped a track or two thinking there may have been an initial difference due to one player already playing when I synced the second, but nothing helped.

So I took a look at the sync wiki (http://wiki.slimdevices.com/index.cgi?Synchronization) and the Transporter is not listed as a device capable of synchronized play. Editing oversight or is there really a problem?

Are there any tricks worth trying to get this working better? I testing using Ogg Vorbis files, so that the difference in network speeds should have been even more of a non-issue.

2007-01-15, 20:26
CatBus wrote:
> Editing oversight or is there really a problem?
oversight. The page probably hasnt' been updated since Transporter hit
the streets.

> Are there any tricks worth trying to get this working better? I
> testing using Ogg Vorbis files, so that the difference in network
> speeds should have been even more of a non-issue.
I've never tried to sync Ogg, but Flac has worked great for me with
Transporter/SB3/SB2 in sync. Perhaps try a different format, make sure
that you have the file types for ogg->ogg set for native and no bitrate
limiting (I know, likely you have already checked, but I have to ask
anyway :)

I have a mixed wired/wireless setup as well, so I wouldn't expect that
to be an obstacle aside from any possible wireless throughput issues.
Try the NetTest plugin just to verify that you have the throughput that
you expect.


2007-01-16, 09:13
I also just considered--I only really ever use the remote-control interface. I went to the web interface to set up the sync but did everything else from the remote control on one device. Perhaps there's different behavior when you set the playlist for both devices from the web interface?

2007-01-16, 09:30
Shouldnt be. The "already-playing" player should restart the song it was playing so that they are both started at the same spot.

2007-01-16, 15:07
Haven't had a chance to install NetTest yet, but I wanted to ask two more questions:

- Could my use of WPA2/AES wireless security be putting a load the processor that might cause such a delay?

- Could certain receivers (for the Transporter) and active speakers (for the Squeezebox) introduce such an obvious delay? (probably only a half-second now that I reconsider it, but still way too long)

I went home briefly and verified that wireless reception at the Squeezebox's location is "excellent" (5 bars, whatever that means) in the Windows' wireless setup screen, with a standard Centrino laptop with no special external antenna.

2007-01-16, 15:16
The way it should work:
. slimserver fills the buffer of both players
. slimserver sends them both a 'start playing'

The difference between the two starts should be minimal (unless you have a very icky network and the packets have to be retransmitted I guess...)

Are you transcoding or anything odd?

WPA2/AES shouldnt be adding any serious load.

2007-01-16, 16:02
No, I'm not transcoding or bandwidth-limiting or anything.

In addition to NetTest, I'm going to try it out with FLAC and see if this is a Vorbis-only issue. I'm assuming kdf has a similar-enough setup to mine that I should be able to get similar results when doing the exact same thing.

2007-01-16, 16:35
Well, FLAC sync works for me as well between an SB and a Transporter. I'm wondering whether you are unwittingly transcoding, either because the ogg-ogg entry in server settings/file formats isn't ticked, or perhaps there is a bug in some table somewhere that tells the server that the transporter is capable of playing ogg natively?

I think you could test this hypothesis by playing some ogg to each device and then looking on the player display to see what type of stream it is getting (arrow right for detailed stream info, then scroll).


2007-01-16, 17:32
How does the synch get off by a full second only seconds into the track?

One is starting before the other?

One has dropouts?

One is playing (significantly) slower than the other? If that's possible, then what does it say about non-synched playback through the SB - can playback speed be faster or slower than it should be?

2007-01-16, 18:43
Hooray! Here's the solution for my problem. Please help me determine what this means.

The fix? In SlimServer, under File Format Conversion Setup, UNCHECK the box next to Ogg Vorbis (built-in). Suddenly everything is synced beautifully.

More on the symptoms: JJZolx was correct, the Squeezebox was starting playback a fraction of a second later than Transporter playback. The offset between the two streams remained constant, it's just the the cacophany was destroying my capacity for rational thought and I believed it was getting worse.

What I think that means? I believe a firmware bug in one or both players, preventing Ogg playback from being able to sync between the two classes of device. By disabling native playback, SlimServer transcodes to a format that syncs without problems (FLAC?).

If you agree with this assessment, let me know. I'll file the bug!


Eric Seaberg
2007-01-17, 08:20
I think it transcodes to LAME, if I'm not mistaken. I had the same problem with TP and SB3 and had to set the SB3 to limit @ 320k. Solved all my problems!! I could tell it was wireless bandwidth, especially, when I'd open up my Powerbook to 'surf' a bit while listening. This ALWAYS made the wireless SB3 stutter.