PDA

View Full Version : FLAC Gaps with Sync'ed players



FortFun
2006-08-22, 20:46
Any word on when we might see gapless playback of flacs when two squeezeboxes are sync'd?

Is this impossible to fix or is there a plan?

I was excited to get a 2nd squeezebox but this kind of sucks since I mainly listen to live recordings.

Thanks!

radish
2006-08-27, 15:44
It is possible, but it's not easy and it's not been done yet (as far as I know).

http://bugs.slimdevices.com/show_bug.cgi?id=259

funkstar
2006-08-28, 08:21
Right now, syncing in a pain. There is a plan in place to re-work how players are kept in sync, but this will take a lot of work. I think you are probably looking at v7.0 until this gets out.

mbonsack
2006-08-28, 09:04
Right now, syncing in a pain. There is a plan in place to re-work how players are kept in sync, but this will take a lot of work. I think you are probably looking at v7.0 until this gets out.

Does anyone know if a) Sonos gets this right, and b) if so, how?

radish
2006-08-28, 11:05
Does anyone know if a) Sonos gets this right, and b) if so, how?

Very interesting point. They claim to be gapless but I don't know if they claim perfect sync.

Kyle
2006-08-28, 12:50
Right now, syncing in a pain. There is a plan in place to re-work how players are kept in sync, but this will take a lot of work. I think you are probably looking at v7.0 until this gets out.
Syncing is a pain? I thought it was easy. If it's a pain, that would affect my decision on getting another SB.

aubuti
2006-08-28, 14:20
It's easy to *tell* the SBs to sync, but it seems that sync'ing performance is highly variable. Some report it does fine, others report lousy results, and some (like me) report both. It depends on a lot of factors, and in my case I suspect that the problems have more to do with my home network than it is my SBs or slimserver. But I haven't completely ruled out the SBs or slimserver yet, or for that matter, the phase of the moon .....

Having wired connections and using one of SBs native formats certainly increases your odds of being able to sync okay. But even in perfect conditions, you're not likely to get gapless and sync'ing with the current software and hardware. That's because the streams tend to diverge, and slimserver re-syncs at track changes. For the same reason, forget about sync'ing internet radio.

lanierb
2006-08-28, 16:36
Syncing is a pain? I thought it was easy. If it's a pain, that would affect my decision on getting another SB.

*Hardware* syncing (between two or more SB's) is smooth/easy, but not entirely gapless. Software (softsqueeze) syncing is a pain because there is inherent delay in the system that's hard to get rid of, that screws up the sync.

Ben Sandee
2006-08-28, 16:57
On 8/28/06, lanierb <lanierb.2d9xgo1156808402 (AT) no-mx (DOT) forums.slimdevices.com>
wrote:
>
>
> Kyle;131825 Wrote:
> > Syncing is a pain? I thought it was easy. If it's a pain, that would
> > affect my decision on getting another SB.
>
> *Hardware* syncing (between two or more SB's) is smooth/easy, but not
> entirely gapless. Software (softsqueeze) syncing is a pain because
> there is inherent delay in the system that's hard to get rid of, that
> screws up the sync.


I have to disagree and I would hate for someone to buy SB's dead-set on
sync'ing them reliably and then have the resulting discussion turn into a
flamefest. I have four slim devices from both the Slimp3 and SB2/3
generations and sync'ing is something I have never been able to do
reliably. However, you may get lucky and it may work great for you. The
truth is, at first when buying the devices I thought that I would sync all
the time but I don't feel as though I miss it now. I haven't tried since
probably the 6.2.x series of software either so it could be working fairly
reliably now I think you will still get the drift during a track until this
bug is fixed:

http://bugs.slimdevices.com/show_bug.cgi?id=259

I suspect that with the introduction of the high-end Transporter, it may
indeed be in the works to solve this problem once and for all and I'm
confident that SlimDevices wouldn't leave the SB2 and SB3 owners behind in
any fix. I have little hope for the older devices because I would guess
that doing this right will require firmware updates but I may very well be
wrong.

BTW, even if this bug is fixed, doing sync over wireless with high quality
(FLAC) audio will be *terribly* bandwidth intensive although the use of
multicasting would mitigate it. I think multicasting would be a major
protocol change but again I'm speculating wildly.

Ben

kdf
2006-08-28, 20:52
On 28-Aug-06, at 8:44 PM, Mark Lanctot wrote:

>
> The big architectural change in 7.0 will be a fine-grained network
> clock
> which is being done specifically to address this.
>
That's an awfully big promise to make on someone else's behalf
-k

andyg
2006-08-28, 20:59
Maybe he is offering to help out. ;) Seriously though, putting in some kind of lightweight NTP/SNTP system is something we want to try to do for 7.0.

Mark Lanctot
2006-08-28, 21:00
OK guys, sheesh, post deleted.

I'd help but I find Perl the most complicated programming language I've ever tried to learn.

kdf
2006-08-28, 21:10
On 28-Aug-06, at 8:57 PM, Mark Lanctot wrote:
>
> Isn't that what it says here?
>
> http://wiki.slimdevices.com/index.cgi?SoftwareRoadmap
>
>> * - Network clock for synchronization.
>> o Owner: dean/andy/richard ?
>> o Status: N/A
>>
yes, but lets include a broader paste...
Future / Untargetted

* - Network clock for synchronization.
o Owner: dean/andy/richard ?
o Status: N/A

first line could be critical there.

the roadmap is a live document, and always in progress.
things change depending on requirements and possibility.

this is part of why there is no promise on time or features.

using 'will be' is perhaps overreaching, unless you yourself have
some bit of code that the rest of us haven't seen yet.

The roadmap is a goal. It is what SD would like to be able to do, and
what every contributor will work toward. It is not fair to be cutting
them off at the knees by
promising it in their name, nor is it fair to the users who will be
expecting fruit of that promise.

-k

mbonsack
2006-08-29, 17:13
[QUOTE=kdf;131891]On 28-Aug-06, at 8:57 PM, Mark Lanctot wrote:
>
> Isn't that what it says here?
>
> http://wiki.slimdevices.com/index.cgi?SoftwareRoadmap
>
>> * - Network clock for synchronization.
>> o Owner: dean/andy/richard ?
>> o Status: N/A
>>
yes, but lets include a broader paste...
Future / Untargetted

My only comment here is that the marketing literature regarding syncing should be toned down or eliminated until this works. There seem to be a few too many corner cases (flac gapless, crossfading, etc.) where syncing doesn't work to claim general support. This is similar to the issues we had six months or so back when people were (rightly so) up in arms about WPA2/wireless support. It simply didn't work in most cases until our new firmware guru came on board, and stating support in the marketing collateral rubbed people the wrong way.

radish
2006-08-29, 19:26
[QUOTE=kdf;131891]On 28-Aug-06, at 8:57
My only comment here is that the marketing literature regarding syncing should be toned down or eliminated until this works. There seem to be a few too many corner cases (flac gapless, crossfading, etc.) where syncing doesn't work to claim general support. This is similar to the issues we had six months or so back when people were (rightly so) up in arms about WPA2/wireless support. It simply didn't work in most cases until our new firmware guru came on board, and stating support in the marketing collateral rubbed people the wrong way.

This isn't quite the same. The problem with gapless & sync isn't that the sync stops working, it's that the gapless stops working. So it would be fair to say that gapless support isn't 100% (it works most of the time but there is room for improvement). You are right about crossfade though, that is really an either/or choice. The good news is that when that infamous enhancement goes in both gapless and crossfade should be sync-compatible.