PDA

View Full Version : still have playback gaps



Robert E. Brown
2004-07-03, 18:55
I got a new Squeezebox in May. When I first tried it, I experienced gaps in
playback about every 30 seconds. I sent an email to this list and someone
suggested upgrading the player and server software. I upgraded to player
firmware 23 and server version 5.1.5. Playback improved considerably. I
now get gaps in playback every 5 minutes, so things are much improved, but
still completely unusable.

My server is a fast Athlon Linux box running Red Hat Linux 7.3. Between the
server and the Squeezebox, packets go through a network switch, a Linksys
wireless ethernet bridge, and finally to a Linksys 802.11b access point.
Both wireless client devices, the Squeezebox and the bridge, report
reasonable signal strength.

I am playing FLAC compressed audio files and sending uncompressed audio to
the player.

When I observe the server, I see low CPU usage. Netstat reports that the
output TCP/IP buffer on the Linux box always has from 20K to 30K of data
available, even when the music stops playing. This indicates that I
probably have a networking problem, not a server problem.

When I use tcpdump on a Macintosh portable to observe the wireless packets,
I see many retransmissions of audio data from the server. It's not uncommon
for the server to transmit the same audio packet 3 times before the player
ACKs them. Here's a typical example:

A 20:42:48.896206 IP loki.bibliotech.com.cslistener > squeezebox.44665:
. 6419620:6421080(1460) ack 1 win 6432
20:42:48.897846 IP loki.bibliotech.com.cslistener > squeezebox.44665: P
6416700:6418160(1460) ack 1 win 6432
20:42:48.899628 IP loki.bibliotech.com.cslistener > squeezebox.44665:
. 6418160:6419620(1460) ack 1 win 6432
A 20:42:48.901362 IP loki.bibliotech.com.cslistener > squeezebox.44665:
. 6419620:6421080(1460) ack 1 win 6432
20:42:48.902651 IP squeezebox.44665 > loki.bibliotech.com.cslistener: . ack
6418160 win 16000
20:42:48.903661 IP squeezebox.44665 > loki.bibliotech.com.cslistener: . ack
6418160 win 16000
A 20:42:48.907800 IP squeezebox.44665 > loki.bibliotech.com.cslistener: . ack
6421080 win 16000
20:42:48.911999 IP loki.bibliotech.com.cslistener > squeezebox.44665:
. 6421080:6422540(1460) ack 1 win 6432
B 20:42:48.926786 IP loki.bibliotech.com.cslistener > squeezebox.44665:
. 6422540:6424000(1460) ack 1 win 6432
A 20:42:48.927296 IP squeezebox.44665 > loki.bibliotech.com.cslistener: . ack
6421080 win 16000
20:42:48.946185 IP loki.bibliotech.com.cslistener > squeezebox.44665:
. 6421080:6422540(1460) ack 1 win 6432
B 20:42:48.947875 IP loki.bibliotech.com.cslistener > squeezebox.44665:
. 6422540:6424000(1460) ack 1 win 6432
B 20:42:48.951145 IP squeezebox.44665 > loki.bibliotech.com.cslistener: . ack
6424000 win 16000
B 20:42:48.952163 IP squeezebox.44665 > loki.bibliotech.com.cslistener: . ack
6424000 win 16000

Maybe I'm just misinterpreting the tcpdump output. To me it looks like the
server is sending data packets more than once and the player is ACKing each
of the copies. I've marked the interesting lines with A and B in the left
margin.

In example A, it looks like the Linux box sent a second copy of the data
packet after 5ms. In case B, however, it waited 20ms before sending the
second copy of a packet. The player took 24ms to ACK the first send.

I would like to debug the problem. What other tools are available? What
other information do you need to assist me?

bob

Andrew W. Donoho
2004-07-04, 01:58
Robert,

On Linux, renicing the slimserver helps. I use the following command:

sudo renice -2 -p XXXXX

It has dramatically reduced my dropouts.

Andrew

On Jul 3, 2004, at 20:55, Robert E. Brown wrote:

>
> I got a new Squeezebox in May. When I first tried it, I experienced
> gaps in
> playback about every 30 seconds. I sent an email to this list and
> someone
> suggested upgrading the player and server software. I upgraded to
> player
> firmware 23 and server version 5.1.5. Playback improved considerably.
> I
> now get gaps in playback every 5 minutes, so things are much improved,
> but
> still completely unusable.
>
> My server is a fast Athlon Linux box running Red Hat Linux 7.3.
> Between the
> server and the Squeezebox, packets go through a network switch, a
> Linksys
> wireless ethernet bridge, and finally to a Linksys 802.11b access
> point.
> Both wireless client devices, the Squeezebox and the bridge, report
> reasonable signal strength.
>
> I am playing FLAC compressed audio files and sending uncompressed
> audio to
> the player.
>
> When I observe the server, I see low CPU usage. Netstat reports that
> the
> output TCP/IP buffer on the Linux box always has from 20K to 30K of
> data
> available, even when the music stops playing. This indicates that I
> probably have a networking problem, not a server problem.
>
> When I use tcpdump on a Macintosh portable to observe the wireless
> packets,
> I see many retransmissions of audio data from the server. It's not
> uncommon
> for the server to transmit the same audio packet 3 times before the
> player
> ACKs them. Here's a typical example:
>
> A 20:42:48.896206 IP loki.bibliotech.com.cslistener >
> squeezebox.44665:
> . 6419620:6421080(1460) ack 1 win 6432
> 20:42:48.897846 IP loki.bibliotech.com.cslistener >
> squeezebox.44665: P
> 6416700:6418160(1460) ack 1 win 6432
> 20:42:48.899628 IP loki.bibliotech.com.cslistener >
> squeezebox.44665:
> . 6418160:6419620(1460) ack 1 win 6432
> A 20:42:48.901362 IP loki.bibliotech.com.cslistener >
> squeezebox.44665:
> . 6419620:6421080(1460) ack 1 win 6432
> 20:42:48.902651 IP squeezebox.44665 >
> loki.bibliotech.com.cslistener: . ack
> 6418160 win 16000
> 20:42:48.903661 IP squeezebox.44665 >
> loki.bibliotech.com.cslistener: . ack
> 6418160 win 16000
> A 20:42:48.907800 IP squeezebox.44665 >
> loki.bibliotech.com.cslistener: . ack
> 6421080 win 16000
> 20:42:48.911999 IP loki.bibliotech.com.cslistener >
> squeezebox.44665:
> . 6421080:6422540(1460) ack 1 win 6432
> B 20:42:48.926786 IP loki.bibliotech.com.cslistener >
> squeezebox.44665:
> . 6422540:6424000(1460) ack 1 win 6432
> A 20:42:48.927296 IP squeezebox.44665 >
> loki.bibliotech.com.cslistener: . ack
> 6421080 win 16000
> 20:42:48.946185 IP loki.bibliotech.com.cslistener >
> squeezebox.44665:
> . 6421080:6422540(1460) ack 1 win 6432
> B 20:42:48.947875 IP loki.bibliotech.com.cslistener >
> squeezebox.44665:
> . 6422540:6424000(1460) ack 1 win 6432
> B 20:42:48.951145 IP squeezebox.44665 >
> loki.bibliotech.com.cslistener: . ack
> 6424000 win 16000
> B 20:42:48.952163 IP squeezebox.44665 >
> loki.bibliotech.com.cslistener: . ack
> 6424000 win 16000
>
> Maybe I'm just misinterpreting the tcpdump output. To me it looks
> like the
> server is sending data packets more than once and the player is ACKing
> each
> of the copies. I've marked the interesting lines with A and B in the
> left
> margin.
>
> In example A, it looks like the Linux box sent a second copy of the
> data
> packet after 5ms. In case B, however, it waited 20ms before sending
> the
> second copy of a packet. The player took 24ms to ACK the first send.
>
> I would like to debug the problem. What other tools are available?
> What
> other information do you need to assist me?
>
> bob
>
>

seanadams
2004-07-06, 10:00
Bob,

What you're seeing in this dump is just plain old timeouts and
retransmissions due to dropped packets. It looks like TCP is behaving
correctly. If you use ethereal instead of TCP dump, it's much easier
to see because it flags the retransmissions for you.

two suggestions here:

- try moving the 802.11b devices to another channel
- try another link... if ethernet is not an option, try powerline
bridges. We've received very good feedback about them.



On Jul 3, 2004, at 6:55 PM, Robert E. Brown wrote:

>
> I got a new Squeezebox in May. When I first tried it, I experienced
> gaps in
> playback about every 30 seconds. I sent an email to this list and
> someone
> suggested upgrading the player and server software. I upgraded to
> player
> firmware 23 and server version 5.1.5. Playback improved considerably.
> I
> now get gaps in playback every 5 minutes, so things are much improved,
> but
> still completely unusable.
>
> My server is a fast Athlon Linux box running Red Hat Linux 7.3.
> Between the
> server and the Squeezebox, packets go through a network switch, a
> Linksys
> wireless ethernet bridge, and finally to a Linksys 802.11b access
> point.
> Both wireless client devices, the Squeezebox and the bridge, report
> reasonable signal strength.
>
> I am playing FLAC compressed audio files and sending uncompressed
> audio to
> the player.
>
> When I observe the server, I see low CPU usage. Netstat reports that
> the
> output TCP/IP buffer on the Linux box always has from 20K to 30K of
> data
> available, even when the music stops playing. This indicates that I
> probably have a networking problem, not a server problem.
>
> When I use tcpdump on a Macintosh portable to observe the wireless
> packets,
> I see many retransmissions of audio data from the server. It's not
> uncommon
> for the server to transmit the same audio packet 3 times before the
> player
> ACKs them. Here's a typical example:
>
> A 20:42:48.896206 IP loki.bibliotech.com.cslistener >
> squeezebox.44665:
> . 6419620:6421080(1460) ack 1 win 6432
> 20:42:48.897846 IP loki.bibliotech.com.cslistener >
> squeezebox.44665: P
> 6416700:6418160(1460) ack 1 win 6432
> 20:42:48.899628 IP loki.bibliotech.com.cslistener >
> squeezebox.44665:
> . 6418160:6419620(1460) ack 1 win 6432
> A 20:42:48.901362 IP loki.bibliotech.com.cslistener >
> squeezebox.44665:
> . 6419620:6421080(1460) ack 1 win 6432
> 20:42:48.902651 IP squeezebox.44665 >
> loki.bibliotech.com.cslistener: . ack
> 6418160 win 16000
> 20:42:48.903661 IP squeezebox.44665 >
> loki.bibliotech.com.cslistener: . ack
> 6418160 win 16000
> A 20:42:48.907800 IP squeezebox.44665 >
> loki.bibliotech.com.cslistener: . ack
> 6421080 win 16000
> 20:42:48.911999 IP loki.bibliotech.com.cslistener >
> squeezebox.44665:
> . 6421080:6422540(1460) ack 1 win 6432
> B 20:42:48.926786 IP loki.bibliotech.com.cslistener >
> squeezebox.44665:
> . 6422540:6424000(1460) ack 1 win 6432
> A 20:42:48.927296 IP squeezebox.44665 >
> loki.bibliotech.com.cslistener: . ack
> 6421080 win 16000
> 20:42:48.946185 IP loki.bibliotech.com.cslistener >
> squeezebox.44665:
> . 6421080:6422540(1460) ack 1 win 6432
> B 20:42:48.947875 IP loki.bibliotech.com.cslistener >
> squeezebox.44665:
> . 6422540:6424000(1460) ack 1 win 6432
> B 20:42:48.951145 IP squeezebox.44665 >
> loki.bibliotech.com.cslistener: . ack
> 6424000 win 16000
> B 20:42:48.952163 IP squeezebox.44665 >
> loki.bibliotech.com.cslistener: . ack
> 6424000 win 16000
>
> Maybe I'm just misinterpreting the tcpdump output. To me it looks
> like the
> server is sending data packets more than once and the player is ACKing
> each
> of the copies. I've marked the interesting lines with A and B in the
> left
> margin.
>
> In example A, it looks like the Linux box sent a second copy of the
> data
> packet after 5ms. In case B, however, it waited 20ms before sending
> the
> second copy of a packet. The player took 24ms to ACK the first send.
>
> I would like to debug the problem. What other tools are available?
> What
> other information do you need to assist me?
>
> bob
>
>