PDA

View Full Version : FW: Tuning Squeezebox buffering parameters



Dan Goodinson
2004-11-15, 03:44
Hi,

Can you give more detail on the outages? I'm seeing something similar,
and am wondering if I should look into this too?

For me, every couple of hours or so, the SB player seems to reboot.
This means that I can be listening to a track and then the music
suddenly stops and the display goes dark. A second later, the SB
splash-screen displays and the player reconnects to the SlimServer. I
can see in my router logs that the player requests a new IP every time
this happens - it seems very much like either the connection is broken
or the player really does completely reboot. It can go for several
hours without issue, but sometimes it happens 2 or 3 times in 30 mins!

I thought maybe it was interference at first, so I've modified some of
my wireless settings (e.g. everything now on a short preamble,
SlimServer IP now static, updated router firmware, updated all network
card drivers etc) but I still see the problem.

My SlimServer is very under-powered: I only have 128MB RAM, so I've got
512MB on order. Maybe it is simply a problem of resources on the
server. But I'm interested in the idea of the buffering - I've enabled
the buffer fullness display and will see if I can catch the issue next
time a crash occurs. It seems to be crashing quite a lot this morning
:(

Do these symptoms match yours?

Cheers,
Dan.

PS: I'm using Slimserver v5.3.1 running on Win2k Advanced Server (CPU
500MHZ, RAM 182MB (!!), page file 4GB). Network is mixture of 810.11b/g
(with SB running at 801.11b as is one other network device), all using
US Robotics hardware (capable of 125mbps performance). Wireless signal
strength approx 85%.

-----Original Message-----
From: discuss-bounces (AT) lists (DOT) slimdevices.com
[mailto:discuss-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of Nicholas
Gianniotis
Sent: 15 November 2004 10:02
To: discuss (AT) lists (DOT) slimdevices.com
Subject: [slim] Tuning Squeezebox buffering parameters


Hi,

I'm wondering how flow control and buffering work between the SlimServer
& Squeezebox, and whether it can be tuned. For example, how many seconds
(or kbytes) of audio does the Squeezebox buffer?

I have about 30,000 flac files in my SlimServer's library and I stream
them to a SB without any bitrate limiting. About once per hour I get a
dropout in playback. I've enabled the buffer fullness display on the SB
and have observed it rapidly drop from 100% to 0% (it only takes about 1
second) whenever these gaps occur. I also detect a spike of intense CPU
activity on my server at these times... I haven't been able to identify
the process but I suspect it might be the SlimServer.

No doubt my server is the cause of the dropouts. But I was wondering if
it's possible to increase the amount of audio buffered by the SB to make
it more resilient to these temporary outtages? Is this a setting that
can be changed?

TIA,
Nico

PS: I've got a network packet trace of one of these dropout events if
anyone at Slim is interested in taking a look... I haven't anaylyzed it
in detail yet, but there is clearly a section where packet gaps between
the server & SB exceed 1000ms (where typically it's < 10ms). This
section corresponds to when the buffer underrun occured.

PPS: My SlimServer runs on a 2.2GHz P4 w/ 1Gb RAM under Solaris 8 x86.
Comms to SB is via 802.11b LAN. Wireless signal strength is excellent
(wireless hub in the same room as SB). SlimServer is v5.3.1.

Nicholas Gianniotis
2004-11-15, 06:30
Dan,

> Can you give more detail on the outages? [...]

It's pretty much as I described. My gut feeling is that the SlimServer
gets busy once in a while (related to the size of my library?), and
doesn't service the tcp/ip stream to the SB. This causes the SB to
play out its entire buffer ending with an underrun. It would help to
know how big this buffer is in terms of kbytes or seconds of playback
at the nominated bitrate.

I think the network packet trace I captured tells an interesting
story. Here's the pertinent section around the time of the dropout,
filtered so we can see the actual transmission of data from the server
to the client:

17300 0.01009 kamakura -> slim1 length: 1514 TCP D=26395 S=9000 Ack=2840251971 Seq=110900045 Len=1460 Win=64240
17301 0.00845 kamakura -> slim1 length: 1514 TCP D=26395 S=9000 Ack=2840251971 Seq=110901505 Len=1460 Win=64240
17302 0.02043 kamakura -> slim1 length: 1514 TCP D=26395 S=9000 Ack=2840251971 Seq=110902965 Len=1460 Win=64240
17303 0.00001 kamakura -> slim1 length: 1514 TCP D=26395 S=9000 Ack=2840251971 Seq=110904425 Len=1460 Win=64240
17304 0.00000 kamakura -> slim1 length: 1514 TCP D=26395 S=9000 Ack=2840251971 Seq=110905885 Len=1460 Win=64240
17305 0.01049 kamakura -> slim1 length: 1514 TCP D=26395 S=9000 Ack=2840251971 Seq=110907345 Len=1460 Win=64240
17306 2.50622 kamakura -> slim1 length: 1514 TCP D=26395 S=9000 Ack=2840251971 Seq=110908805 Len=1460 Win=64240
17307 0.00094 kamakura -> slim1 length: 1514 TCP D=26395 S=9000 Ack=2840251971 Seq=110910285 Len=1460 Win=64240
17308 0.00000 kamakura -> slim1 length: 1514 TCP D=26395 S=9000 Ack=2840251971 Seq=110911745 Len=1460 Win=64240
17309 0.01297 kamakura -> slim1 length: 1514 TCP D=26395 S=9000 Ack=2840251971 Seq=110913205 Len=1460 Win=64240
17310 0.00001 kamakura -> slim1 length: 1514 TCP D=26395 S=9000 Ack=2840251971 Seq=110914665 Len=1460 Win=64240
17311 0.00483 kamakura -> slim1 length: 1514 TCP D=26395 S=9000 Ack=2840251971 Seq=110916125 Len=1460 Win=64240
17312 0.00001 kamakura -> slim1 length: 1514 TCP D=26395 S=9000 Ack=2840251971 Seq=110917585 Len=1460 Win=64240

Col 1 = packet #, col 2 = interpacket (delta) time, "kamakura" =
SlimServer and "slim1" = Squeezebox. This trace clearly shows packet
#17306 was transmitted a whopping 2.5 seconds after the previous
packet in the stream. This is very likely what caused the underrun.
Note the average interpacket delay before and after the gap was
0.00569s - 5.7ms - an acceptable value.

Now, it's another task altogether to figure out *why* the server went
out to lunch for 2.5s (remember, none of us run proper real-time
operating systems - so there are no guarantees whatsoever when it
comes to process or thread scheduling)... but whatever the answer is,
the hope is that we can configure the Squeezebox to buffer more than
2.5s music to ride out these interruptions when they occur.

Regards,
Nico