PDA

View Full Version : still have playback gaps



Jason
2004-07-04, 08:13
Wireless does not always have enough bandwidth to support uncompressed
output. Do you get similar dropouts when you bandwidth limit your output to
320kpbs?

Do you get dropouts with other formats or only FLAC?

Re-transmissions are to be expected in a wireless environment and could be
caused by anything from a neighbor's wireless access point interfering with
yours to normal packet loss on the wireless LAN.

If you hardwire the squeezebox to the server do the dropouts stop?



-----Original Message-----
From: discuss-bounces (AT) lists (DOT) slimdevices.com
[mailto:discuss-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of Robert E. Brown
Sent: Saturday, July 03, 2004 7:56 PM
To: discuss (AT) lists (DOT) slimdevices.com
Subject: [slim] still have playback gaps


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

Robert E. Brown
2004-07-04, 15:33
Wireless does have enough bandwidth to support uncompress audio, if the
software and hardware are well designed, are functioning properly, and if
there's sufficient signal strength, etc.

Now the Squeezebox only seems to have a second or two of buffer space, which
I'd say is arguably a botch. It means that the server host really can't do
any heavy processing and I can't make heavy use of my wireless LAN and
expect the audio to function properly. But I'm doing neither of these
things.

I don't think I'm seeing retransmissions of corrupt packets. The Linksys
bridge is sending the same packet more than once and the Squeezebox is
ACKing the packet more than once. If the first send of the packet were
corrupted, then the access point wouldn't even rebroadcast it, so the
Squeezebox would never see it. I now believe the Linksys bridge is just
defective. I've done a bit more snooping with tcpdump -- the Linux box is
not to blame. It's not resending packets.

Also, after a long session with Linksys technical support, they indicated
that the WET11 bridge has "issues" with streaming data, and recommended that
I upgrade the firmware. Sadly, I have to find someone with a Windows PC in
order to do this. It might be easier to just buy a new wireless bridge.

bob

====================

From: "Jason" <jason (AT) pagefamily (DOT) net>
Date: Sun, 4 Jul 2004 09:13:03 -0600
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcRhazffE2ZTaaCMTp+k5wp6doKCXQAbfbbw
Reply-To: Slim Devices Discussion <discuss (AT) lists (DOT) slimdevices.com>
Sender: discuss-bounces (AT) lists (DOT) slimdevices.com

Wireless does not always have enough bandwidth to support uncompressed
output. Do you get similar dropouts when you bandwidth limit your output to
320kpbs?

Do you get dropouts with other formats or only FLAC?

Re-transmissions are to be expected in a wireless environment and could be
caused by anything from a neighbor's wireless access point interfering with
yours to normal packet loss on the wireless LAN.

If you hardwire the squeezebox to the server do the dropouts stop?



-----Original Message-----
From: discuss-bounces (AT) lists (DOT) slimdevices.com
[mailto:discuss-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of Robert E. Brown
Sent: Saturday, July 03, 2004 7:56 PM
To: discuss (AT) lists (DOT) slimdevices.com
Subject: [slim] still have playback gaps


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