syncing feelin'

[Philip D Hopely]

Hi,

I wish to workaround/eliminate the inter-track gap while synced, as per
bugs 598 and 750, etc. I am using 2 squeezeboxes & cygwin, and am only
interested in flac or shn & wav, etc.

The below sucks yet initially works for .wav files - while seamless, the
players fall out of sync over time:

Slim/Player/
diff Source.pm Source.pm.orig
709d708
< if (0) {
721d719
< }

Rather than the existing method of syncing @ head of track, I believe that:
adding a relative timestamp from the server every so many data frames - and
the clients sync themselves relatively by way of that timestamp - is
more reliable. At least, thats how its done in a few other parallel
universes

Are you guys planning any protocol change like that, and if not, can I
have a copy to the source of the o.s. (& tech specs & dev environment if
its not cygwin/linux) for the squeezebox to implement?

And if it makes you guys truckloads of money (fwiw, I know a number of
people who will buy these if this one bug gets fixed nicely), can I have
a small fraction please?


cheers,
Phil

[dean]

On Jan 20, 2005, at 2:12 PM, Philip D Hopely wrote:
> Rather than the existing method of syncing @ head of track, I believe
> that:
> adding a relative timestamp from the server every so many data frames
> - and
> the clients sync themselves relatively by way of that timestamp - is
> more reliable. At least, thats how its done in a few other parallel
> universes
Yeah. We may have the ability to tune the output sample rate to ensure
that the players stay in sync (this has been documented in a bug, but
I'm offline right now, so I don't have the number off the top of my
head.) The problem is a little like NTP, and it's non-trivial, but it
would be great.


> Are you guys planning any protocol change like that, and if not, can I
> have a copy to the source of the o.s. (& tech specs & dev environment
> if
> its not cygwin/linux) for the squeezebox to implement?
While much of the development tool chain for Squeezebox is GNU, the OS
is proprietary and we can't release the source yet. We're trying to
work out an arrangement with the vendor to allow open development.

> And if it makes you guys truckloads of money (fwiw, I know a number of
> people who will buy these if this one bug gets fixed nicely), can I
> have
> a small fraction please?
A small fraction? Yes.

-dean