Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 2 of 2
  1. #1
    Dan Goodinson
    Guest

    FW: Tuning Squeezebox buffering parameters

    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.

  2. #2
    Nicholas Gianniotis
    Guest

    FW: Tuning Squeezebox buffering parameters

    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •