Help wanted: Softsqueeze sync problem

[rtitmuss]

Hi,

I have spend a few more evenings this week trying to work out why sync does
not work correctly with Softsqueeze, and at last have made some progress.
First I needed to iron out a few buffer problems in the audio layer of
Softsqueeze, and managed to get PCM streams is sync (at least with Java
1.5beta1, not sure about earlier Java releases yet).

MP3's are proving _much_ harder to sort out. Using my current development
version of Softsqueeze and a nightly from this week, I see the following:
- Squeezebox and Softsqueeze are synced, but stopped.
- Press 'play'. The mp3 track starts, and plays in sync.
- The track plays out, and the next track is queued in the buffer.
- It is not in sync, Softsqueeze leads by about 1 second. (*)
- Press 'play'. The track restarts, this time in sync.

This is easily repeatable. Further investigation shows that the slimserver
actually does not stream the full track at *, the first 32768 bytes appear
to be missing. You can find an Ethereal trace (captured on the machine
running Softsqueeze) showing this at
http://softsqueeze.sourceforge.net/sync-trace.pcap. The HTTP response
headers are at packets 354 and 1029. In the headers it is clear that the
same file is being played, but the stream data in the subsequent packets is
different.

I've spent a couple of hours browsing around the slimserver code (mainly
Web/HTTP.pm and Player/Source.pm) and can see no reason why this is
happening.

So, is this a slimserver bug, or is it working as designed?

Help!
Richard

[dean]

Hi Richard,

That off-by-32768 isn't expected to me. I'm not sure what's going on
there.

Are you seeing that different data is being served to SoftSqueeze and
Squeezebox at the beginning of subsequent tracks when played through
(that would explain why they aren't in sync) or is the same data being
sent to both, just missing the first 32k bytes?

-dean

On Jun 17, 2004, at 3:25 PM, Richard Titmuss wrote:

> Hi,
>
> I have spend a few more evenings this week trying to work out why sync
> does
> not work correctly with Softsqueeze, and at last have made some
> progress.
> First I needed to iron out a few buffer problems in the audio layer of
> Softsqueeze, and managed to get PCM streams is sync (at least with Java
> 1.5beta1, not sure about earlier Java releases yet).
>
> MP3's are proving _much_ harder to sort out. Using my current
> development
> version of Softsqueeze and a nightly from this week, I see the
> following:
> - Squeezebox and Softsqueeze are synced, but stopped.
> - Press 'play'. The mp3 track starts, and plays in sync.
> - The track plays out, and the next track is queued in the buffer.
> - It is not in sync, Softsqueeze leads by about 1 second. (*)
> - Press 'play'. The track restarts, this time in sync.
>
> This is easily repeatable. Further investigation shows that the
> slimserver
> actually does not stream the full track at *, the first 32768 bytes
> appear
> to be missing. You can find an Ethereal trace (captured on the machine
> running Softsqueeze) showing this at
> http://softsqueeze.sourceforge.net/sync-trace.pcap. The HTTP response
> headers are at packets 354 and 1029. In the headers it is clear that
> the
> same file is being played, but the stream data in the subsequent
> packets is
> different.
>
> I've spent a couple of hours browsing around the slimserver code
> (mainly
> Web/HTTP.pm and Player/Source.pm) and can see no reason why this is
> happening.
>
> So, is this a slimserver bug, or is it working as designed?
>
> Help!
> Richard
>
>
>
>
>

[rtitmuss]

Dean,

I captured a packet trace on the server, your right Softsqueeze and the
Squeezebox do get different data for the subsquent tracks. I have tracked
this down to a problem in HTTP.pm, where a test needs updating to include
the softqueeze player model. Sync works really well now

A patch is attached. Would it be possible to get this into 5.2?

Thanks,
Richard



----- Original Message -----
From: "dean blackketter" <dean (AT) slimdevices (DOT) com>
To: "Slim Devices Developers" <developers (AT) lists (DOT) slimdevices.com>
Sent: Thursday, June 17, 2004 11:55 PM
Subject: Re: [Developers] Help wanted: Softsqueeze sync problem


> Hi Richard,
>
> That off-by-32768 isn't expected to me. I'm not sure what's going on
> there.
>
> Are you seeing that different data is being served to SoftSqueeze and
> Squeezebox at the beginning of subsequent tracks when played through
> (that would explain why they aren't in sync) or is the same data being
> sent to both, just missing the first 32k bytes?
>
> -dean
>
> On Jun 17, 2004, at 3:25 PM, Richard Titmuss wrote:
>
> > Hi,
> >
> > I have spend a few more evenings this week trying to work out why sync
> > does
> > not work correctly with Softsqueeze, and at last have made some
> > progress.
> > First I needed to iron out a few buffer problems in the audio layer of
> > Softsqueeze, and managed to get PCM streams is sync (at least with Java
> > 1.5beta1, not sure about earlier Java releases yet).
> >
> > MP3's are proving _much_ harder to sort out. Using my current
> > development
> > version of Softsqueeze and a nightly from this week, I see the
> > following:
> > - Squeezebox and Softsqueeze are synced, but stopped.
> > - Press 'play'. The mp3 track starts, and plays in sync.
> > - The track plays out, and the next track is queued in the buffer.
> > - It is not in sync, Softsqueeze leads by about 1 second. (*)
> > - Press 'play'. The track restarts, this time in sync.
> >
> > This is easily repeatable. Further investigation shows that the
> > slimserver
> > actually does not stream the full track at *, the first 32768 bytes
> > appear
> > to be missing. You can find an Ethereal trace (captured on the machine
> > running Softsqueeze) showing this at
> > http://softsqueeze.sourceforge.net/sync-trace.pcap. The HTTP response
> > headers are at packets 354 and 1029. In the headers it is clear that
> > the
> > same file is being played, but the stream data in the subsequent
> > packets is
> > different.
> >
> > I've spent a couple of hours browsing around the slimserver code
> > (mainly
> > Web/HTTP.pm and Player/Source.pm) and can see no reason why this is
> > happening.
> >
> > So, is this a slimserver bug, or is it working as designed?
> >
> > Help!
> > Richard
> >
> >
> >
> >
> >

[kdf]

This probably needs to be a $client->cansync() test or some other combined
attribute. Surely other player models will come along and will then need adding
to those lines as well.
-kdf

Quoting Richard Titmuss <richard_titmuss (AT) yahoo (DOT) co.uk>:

> Dean,
>
> I captured a packet trace on the server, your right Softsqueeze and the
> Squeezebox do get different data for the subsquent tracks. I have tracked
> this down to a problem in HTTP.pm, where a test needs updating to include
> the softqueeze player model. Sync works really well now
>
> A patch is attached. Would it be possible to get this into 5.2?
>
> Thanks,
> Richard
>
>
>
> ----- Original Message -----
> From: "dean blackketter" <dean (AT) slimdevices (DOT) com>
> To: "Slim Devices Developers" <developers (AT) lists (DOT) slimdevices.com>
> Sent: Thursday, June 17, 2004 11:55 PM
> Subject: Re: [Developers] Help wanted: Softsqueeze sync problem
>
>
> > Hi Richard,
> >
> > That off-by-32768 isn't expected to me. I'm not sure what's going on
> > there.
> >
> > Are you seeing that different data is being served to SoftSqueeze and
> > Squeezebox at the beginning of subsequent tracks when played through
> > (that would explain why they aren't in sync) or is the same data being
> > sent to both, just missing the first 32k bytes?
> >
> > -dean
> >
> > On Jun 17, 2004, at 3:25 PM, Richard Titmuss wrote:
> >
> > > Hi,
> > >
> > > I have spend a few more evenings this week trying to work out why sync
> > > does
> > > not work correctly with Softsqueeze, and at last have made some
> > > progress.
> > > First I needed to iron out a few buffer problems in the audio layer of
> > > Softsqueeze, and managed to get PCM streams is sync (at least with Java
> > > 1.5beta1, not sure about earlier Java releases yet).
> > >
> > > MP3's are proving _much_ harder to sort out. Using my current
> > > development
> > > version of Softsqueeze and a nightly from this week, I see the
> > > following:
> > > - Squeezebox and Softsqueeze are synced, but stopped.
> > > - Press 'play'. The mp3 track starts, and plays in sync.
> > > - The track plays out, and the next track is queued in the buffer.
> > > - It is not in sync, Softsqueeze leads by about 1 second. (*)
> > > - Press 'play'. The track restarts, this time in sync.
> > >
> > > This is easily repeatable. Further investigation shows that the
> > > slimserver
> > > actually does not stream the full track at *, the first 32768 bytes
> > > appear
> > > to be missing. You can find an Ethereal trace (captured on the machine
> > > running Softsqueeze) showing this at
> > > http://softsqueeze.sourceforge.net/sync-trace.pcap. The HTTP response
> > > headers are at packets 354 and 1029. In the headers it is clear that
> > > the
> > > same file is being played, but the stream data in the subsequent
> > > packets is
> > > different.
> > >
> > > I've spent a couple of hours browsing around the slimserver code
> > > (mainly
> > > Web/HTTP.pm and Player/Source.pm) and can see no reason why this is
> > > happening.
> > >
> > > So, is this a slimserver bug, or is it working as designed?
> > >
> > > Help!
> > > Richard
> > >
> > >
> > >
> > >
> > >

[dean]

Thanks. Will apply for 5.2...

On Jun 18, 2004, at 12:52 PM, Richard Titmuss wrote:

> Dean,
>
> I captured a packet trace on the server, your right Softsqueeze and the
> Squeezebox do get different data for the subsquent tracks. I have
> tracked
> this down to a problem in HTTP.pm, where a test needs updating to
> include
> the softqueeze player model. Sync works really well now
>
> A patch is attached. Would it be possible to get this into 5.2?
>
> Thanks,
> Richard
>
>
>
> ----- Original Message -----
> From: "dean blackketter" <dean (AT) slimdevices (DOT) com>
> To: "Slim Devices Developers" <developers (AT) lists (DOT) slimdevices.com>
> Sent: Thursday, June 17, 2004 11:55 PM
> Subject: Re: [Developers] Help wanted: Softsqueeze sync problem
>
>
>> Hi Richard,
>>
>> That off-by-32768 isn't expected to me. I'm not sure what's going on
>> there.
>>
>> Are you seeing that different data is being served to SoftSqueeze and
>> Squeezebox at the beginning of subsequent tracks when played through
>> (that would explain why they aren't in sync) or is the same data being
>> sent to both, just missing the first 32k bytes?
>>
>> -dean
>>
>> On Jun 17, 2004, at 3:25 PM, Richard Titmuss wrote:
>>
>>> Hi,
>>>
>>> I have spend a few more evenings this week trying to work out why
>>> sync
>>> does
>>> not work correctly with Softsqueeze, and at last have made some
>>> progress.
>>> First I needed to iron out a few buffer problems in the audio layer
>>> of
>>> Softsqueeze, and managed to get PCM streams is sync (at least with
>>> Java
>>> 1.5beta1, not sure about earlier Java releases yet).
>>>
>>> MP3's are proving _much_ harder to sort out. Using my current
>>> development
>>> version of Softsqueeze and a nightly from this week, I see the
>>> following:
>>> - Squeezebox and Softsqueeze are synced, but stopped.
>>> - Press 'play'. The mp3 track starts, and plays in sync.
>>> - The track plays out, and the next track is queued in the buffer.
>>> - It is not in sync, Softsqueeze leads by about 1 second. (*)
>>> - Press 'play'. The track restarts, this time in sync.
>>>
>>> This is easily repeatable. Further investigation shows that the
>>> slimserver
>>> actually does not stream the full track at *, the first 32768 bytes
>>> appear
>>> to be missing. You can find an Ethereal trace (captured on the
>>> machine
>>> running Softsqueeze) showing this at
>>> http://softsqueeze.sourceforge.net/sync-trace.pcap. The HTTP response
>>> headers are at packets 354 and 1029. In the headers it is clear that
>>> the
>>> same file is being played, but the stream data in the subsequent
>>> packets is
>>> different.
>>>
>>> I've spent a couple of hours browsing around the slimserver code
>>> (mainly
>>> Web/HTTP.pm and Player/Source.pm) and can see no reason why this is
>>> happening.
>>>
>>> So, is this a slimserver bug, or is it working as designed?
>>>
>>> Help!
>>> Richard
>>>
>>>
>>>
>>>
>>>

[dean]

Agreed.

On Jun 18, 2004, at 1:01 PM, kdf wrote:

> This probably needs to be a $client->cansync() test or some other
> combined
> attribute. Surely other player models will come along and will then
> need adding
> to those lines as well.
> -kdf
>
> Quoting Richard Titmuss <richard_titmuss (AT) yahoo (DOT) co.uk>:
>
>> Dean,
>>
>> I captured a packet trace on the server, your right Softsqueeze and
>> the
>> Squeezebox do get different data for the subsquent tracks. I have
>> tracked
>> this down to a problem in HTTP.pm, where a test needs updating to
>> include
>> the softqueeze player model. Sync works really well now
>>
>> A patch is attached. Would it be possible to get this into 5.2?
>>
>> Thanks,
>> Richard
>>
>>
>>
>> ----- Original Message -----
>> From: "dean blackketter" <dean (AT) slimdevices (DOT) com>
>> To: "Slim Devices Developers" <developers (AT) lists (DOT) slimdevices.com>
>> Sent: Thursday, June 17, 2004 11:55 PM
>> Subject: Re: [Developers] Help wanted: Softsqueeze sync problem
>>
>>
>>> Hi Richard,
>>>
>>> That off-by-32768 isn't expected to me. I'm not sure what's going on
>>> there.
>>>
>>> Are you seeing that different data is being served to SoftSqueeze and
>>> Squeezebox at the beginning of subsequent tracks when played through
>>> (that would explain why they aren't in sync) or is the same data
>>> being
>>> sent to both, just missing the first 32k bytes?
>>>
>>> -dean
>>>
>>> On Jun 17, 2004, at 3:25 PM, Richard Titmuss wrote:
>>>
>>>> Hi,
>>>>
>>>> I have spend a few more evenings this week trying to work out why
>>>> sync
>>>> does
>>>> not work correctly with Softsqueeze, and at last have made some
>>>> progress.
>>>> First I needed to iron out a few buffer problems in the audio layer
>>>> of
>>>> Softsqueeze, and managed to get PCM streams is sync (at least with
>>>> Java
>>>> 1.5beta1, not sure about earlier Java releases yet).
>>>>
>>>> MP3's are proving _much_ harder to sort out. Using my current
>>>> development
>>>> version of Softsqueeze and a nightly from this week, I see the
>>>> following:
>>>> - Squeezebox and Softsqueeze are synced, but stopped.
>>>> - Press 'play'. The mp3 track starts, and plays in sync.
>>>> - The track plays out, and the next track is queued in the buffer.
>>>> - It is not in sync, Softsqueeze leads by about 1 second. (*)
>>>> - Press 'play'. The track restarts, this time in sync.
>>>>
>>>> This is easily repeatable. Further investigation shows that the
>>>> slimserver
>>>> actually does not stream the full track at *, the first 32768 bytes
>>>> appear
>>>> to be missing. You can find an Ethereal trace (captured on the
>>>> machine
>>>> running Softsqueeze) showing this at
>>>> http://softsqueeze.sourceforge.net/sync-trace.pcap. The HTTP
>>>> response
>>>> headers are at packets 354 and 1029. In the headers it is clear that
>>>> the
>>>> same file is being played, but the stream data in the subsequent
>>>> packets is
>>>> different.
>>>>
>>>> I've spent a couple of hours browsing around the slimserver code
>>>> (mainly
>>>> Web/HTTP.pm and Player/Source.pm) and can see no reason why this is
>>>> happening.
>>>>
>>>> So, is this a slimserver bug, or is it working as designed?
>>>>
>>>> Help!
>>>> Richard
>>>>
>>>>
>>>>
>>>>
>>>>

[kdf]

Would it make sense to file an enahancement for expanding the client object to
cover some sort of sync attribute and bandwidth attribute? Other comments can
be added if there are other attributes I'm leaving out. There are probably
several cases where $client->attribute eq 'x' is a repeated test.

-kdf

Quoting dean blackketter <dean (AT) slimdevices (DOT) com>:

> Agreed.
>
> On Jun 18, 2004, at 1:01 PM, kdf wrote:
>
> > This probably needs to be a $client->cansync() test or some other
> > combined
> > attribute. Surely other player models will come along and will then
> > need adding
> > to those lines as well.
> > -kdf
> >
> > Quoting Richard Titmuss <richard_titmuss (AT) yahoo (DOT) co.uk>:
> >
> >> Dean,
> >>
> >> I captured a packet trace on the server, your right Softsqueeze and
> >> the
> >> Squeezebox do get different data for the subsquent tracks. I have
> >> tracked
> >> this down to a problem in HTTP.pm, where a test needs updating to
> >> include
> >> the softqueeze player model. Sync works really well now
> >>
> >> A patch is attached. Would it be possible to get this into 5.2?
> >>
> >> Thanks,
> >> Richard
> >>
> >>
> >>
> >> ----- Original Message -----
> >> From: "dean blackketter" <dean (AT) slimdevices (DOT) com>
> >> To: "Slim Devices Developers" <developers (AT) lists (DOT) slimdevices.com>
> >> Sent: Thursday, June 17, 2004 11:55 PM
> >> Subject: Re: [Developers] Help wanted: Softsqueeze sync problem
> >>
> >>
> >>> Hi Richard,
> >>>
> >>> That off-by-32768 isn't expected to me. I'm not sure what's going on
> >>> there.
> >>>
> >>> Are you seeing that different data is being served to SoftSqueeze and
> >>> Squeezebox at the beginning of subsequent tracks when played through
> >>> (that would explain why they aren't in sync) or is the same data
> >>> being
> >>> sent to both, just missing the first 32k bytes?
> >>>
> >>> -dean
> >>>
> >>> On Jun 17, 2004, at 3:25 PM, Richard Titmuss wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I have spend a few more evenings this week trying to work out why
> >>>> sync
> >>>> does
> >>>> not work correctly with Softsqueeze, and at last have made some
> >>>> progress.
> >>>> First I needed to iron out a few buffer problems in the audio layer
> >>>> of
> >>>> Softsqueeze, and managed to get PCM streams is sync (at least with
> >>>> Java
> >>>> 1.5beta1, not sure about earlier Java releases yet).
> >>>>
> >>>> MP3's are proving _much_ harder to sort out. Using my current
> >>>> development
> >>>> version of Softsqueeze and a nightly from this week, I see the
> >>>> following:
> >>>> - Squeezebox and Softsqueeze are synced, but stopped.
> >>>> - Press 'play'. The mp3 track starts, and plays in sync.
> >>>> - The track plays out, and the next track is queued in the buffer.
> >>>> - It is not in sync, Softsqueeze leads by about 1 second. (*)
> >>>> - Press 'play'. The track restarts, this time in sync.
> >>>>
> >>>> This is easily repeatable. Further investigation shows that the
> >>>> slimserver
> >>>> actually does not stream the full track at *, the first 32768 bytes
> >>>> appear
> >>>> to be missing. You can find an Ethereal trace (captured on the
> >>>> machine
> >>>> running Softsqueeze) showing this at
> >>>> http://softsqueeze.sourceforge.net/sync-trace.pcap. The HTTP
> >>>> response
> >>>> headers are at packets 354 and 1029. In the headers it is clear that
> >>>> the
> >>>> same file is being played, but the stream data in the subsequent
> >>>> packets is
> >>>> different.
> >>>>
> >>>> I've spent a couple of hours browsing around the slimserver code
> >>>> (mainly
> >>>> Web/HTTP.pm and Player/Source.pm) and can see no reason why this is
> >>>> happening.
> >>>>
> >>>> So, is this a slimserver bug, or is it working as designed?
> >>>>
> >>>> Help!
> >>>> Richard
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>

[rtitmuss]

I was thinking along the lines of a $client->slimproto() test, that could
also be used in Utils::Prefs::maxRate. The tests are really if the devices
use the slimproto, rather than in particular support sync.

I was trying to keep the changes to a minimum at the moment. Would you like
me to do the bigger patch now, or post 5.2?

Regards,
Richard


----- Original Message -----
From: "dean blackketter" <dean (AT) slimdevices (DOT) com>
To: "Slim Devices Developers" <developers (AT) lists (DOT) slimdevices.com>
Sent: Friday, June 18, 2004 9:16 PM
Subject: Re: [Developers] Help wanted: Softsqueeze sync problem


> Agreed.
>
> On Jun 18, 2004, at 1:01 PM, kdf wrote:
>
> > This probably needs to be a $client->cansync() test or some other
> > combined
> > attribute. Surely other player models will come along and will then
> > need adding
> > to those lines as well.
> > -kdf
> >
> > Quoting Richard Titmuss <richard_titmuss (AT) yahoo (DOT) co.uk>:
> >
> >> Dean,
> >>
> >> I captured a packet trace on the server, your right Softsqueeze and
> >> the
> >> Squeezebox do get different data for the subsquent tracks. I have
> >> tracked
> >> this down to a problem in HTTP.pm, where a test needs updating to
> >> include
> >> the softqueeze player model. Sync works really well now
> >>
> >> A patch is attached. Would it be possible to get this into 5.2?
> >>
> >> Thanks,
> >> Richard
> >>
> >>
> >>
> >> ----- Original Message -----
> >> From: "dean blackketter" <dean (AT) slimdevices (DOT) com>
> >> To: "Slim Devices Developers" <developers (AT) lists (DOT) slimdevices.com>
> >> Sent: Thursday, June 17, 2004 11:55 PM
> >> Subject: Re: [Developers] Help wanted: Softsqueeze sync problem
> >>
> >>
> >>> Hi Richard,
> >>>
> >>> That off-by-32768 isn't expected to me. I'm not sure what's going on
> >>> there.
> >>>
> >>> Are you seeing that different data is being served to SoftSqueeze and
> >>> Squeezebox at the beginning of subsequent tracks when played through
> >>> (that would explain why they aren't in sync) or is the same data
> >>> being
> >>> sent to both, just missing the first 32k bytes?
> >>>
> >>> -dean
> >>>
> >>> On Jun 17, 2004, at 3:25 PM, Richard Titmuss wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I have spend a few more evenings this week trying to work out why
> >>>> sync
> >>>> does
> >>>> not work correctly with Softsqueeze, and at last have made some
> >>>> progress.
> >>>> First I needed to iron out a few buffer problems in the audio layer
> >>>> of
> >>>> Softsqueeze, and managed to get PCM streams is sync (at least with
> >>>> Java
> >>>> 1.5beta1, not sure about earlier Java releases yet).
> >>>>
> >>>> MP3's are proving _much_ harder to sort out. Using my current
> >>>> development
> >>>> version of Softsqueeze and a nightly from this week, I see the
> >>>> following:
> >>>> - Squeezebox and Softsqueeze are synced, but stopped.
> >>>> - Press 'play'. The mp3 track starts, and plays in sync.
> >>>> - The track plays out, and the next track is queued in the buffer.
> >>>> - It is not in sync, Softsqueeze leads by about 1 second. (*)
> >>>> - Press 'play'. The track restarts, this time in sync.
> >>>>
> >>>> This is easily repeatable. Further investigation shows that the
> >>>> slimserver
> >>>> actually does not stream the full track at *, the first 32768 bytes
> >>>> appear
> >>>> to be missing. You can find an Ethereal trace (captured on the
> >>>> machine
> >>>> running Softsqueeze) showing this at
> >>>> http://softsqueeze.sourceforge.net/sync-trace.pcap. The HTTP
> >>>> response
> >>>> headers are at packets 354 and 1029. In the headers it is clear that
> >>>> the
> >>>> same file is being played, but the stream data in the subsequent
> >>>> packets is
> >>>> different.
> >>>>
> >>>> I've spent a couple of hours browsing around the slimserver code
> >>>> (mainly
> >>>> Web/HTTP.pm and Player/Source.pm) and can see no reason why this is
> >>>> happening.
> >>>>
> >>>> So, is this a slimserver bug, or is it working as designed?
> >>>>
> >>>> Help!
> >>>> Richard
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>

[dean]

Let's fix it cleanly post 5.2.


On Jun 18, 2004, at 1:28 PM, Richard Titmuss wrote:

> I was thinking along the lines of a $client->slimproto() test, that
> could
> also be used in Utils::Prefs::maxRate. The tests are really if the
> devices
> use the slimproto, rather than in particular support sync.
>
> I was trying to keep the changes to a minimum at the moment. Would you
> like
> me to do the bigger patch now, or post 5.2?
>
> Regards,
> Richard