Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 6 of 6
  1. #1
    Simon Turner
    Guest

    Squeezebox: Sound drop out with Flac files

    Every now and again (av once per song perhaps) I'll get a second or two of
    silnec during a song. I have the Progress Indicator set to Show Buffer
    Fullness and can see that the buffer momentarily (and very instantly) drops
    from it's usual constant full position to zero.

    This does not happen when I play MP3s (even v. hi quality rips
    e.g --alt-extreme or 320CBR), It only happens when I play Flacs (I don't use
    any other formats).

    These are my particulars:
    Squeezebox. Firmware 8.
    SlimServer 5.1.1
    Windows XP
    Wireless signal strength 42%

    Condition of PC - RAM and processing power very underutilised. Minimal
    number of other services running.

    Any suggestions very welcome
    Thanks
    Simon Turner
    Brighton UK

  2. #2
    Stuart Hickinbottom
    Guest

    Squeezebox: Sound drop out with Flac files

    I, too, have experienced this. At first I thought it might be a problem in
    the encoded FLACs, but replaying them causes drops in different places
    thus ruling out this possibility.

    I've checked the server and it's definitely not working hard either in
    terms of network, CPU or disk activity.

    I have the Squeezebox operating over the wireless and so I wondered
    whether that was a factor. The Squeezebox indicates about 60% signal
    strength, which might be relevant, but if it wasn't able to stream fast
    enough I would have expected a gradual drain being visible on the buffer
    meter, which is not the case (it suddenly drops to zero once the player
    goes silent).

    I've configured SlimServer to encode to MP3, via LAME, when streaming
    FLACs over the internet. I don't experience this problem via this channel,
    which makes me think that the FLAC decoding is working perfectly and it's
    just something to do with the SlimServer/Squeezebox route when playing
    FLACs.

    I too am using v5.1.1 with firmware 8, although I'm using a Linux server.

    Hope that's enough information to be helpful. I'm not even sure I want to
    encode everything as FLACs (192kbit MP3s sound nice enough to me), so this
    isn't necessarily a big deal for me.

    Stuart


    On Sun, 7 Mar 2004 10:31:23 -0000, Simon Turner <simon (AT) brighton (DOT) co.uk>
    wrote:

    > Every now and again (av once per song perhaps) I'll get a second or two
    > of
    > silnec during a song. I have the Progress Indicator set to Show Buffer
    > Fullness and can see that the buffer momentarily (and very instantly)
    > drops
    > from it's usual constant full position to zero.
    >
    > This does not happen when I play MP3s (even v. hi quality rips
    > e.g --alt-extreme or 320CBR), It only happens when I play Flacs (I don't
    > use
    > any other formats).
    >
    > These are my particulars:
    > Squeezebox. Firmware 8.
    > SlimServer 5.1.1
    > Windows XP
    > Wireless signal strength 42%
    >
    > Condition of PC - RAM and processing power very underutilised. Minimal
    > number of other services running.
    >
    > Any suggestions very welcome
    > Thanks
    > Simon Turner
    > Brighton UK
    >
    >
    >

  3. #3
    Andrew W. Donoho
    Guest

    Squeezebox: Sound drop out with Flac files

    Simon and Stuart,

    FLAC, like AAC, decodes to either WAV or AIFF. This consumes a great
    deal more bandwidth than an MP3 that is decoded in the SqueezeBox (1.5
    Mb/s versus 320 kb/s for highest quality MP3).

    One thing you can do to minimize retransmissions on wireless is to
    disable WEP security. WEP security can chew up a significant amount of
    your approximately 6 Mb/s of real wireless bandwidth (upwards of 20% or
    more). In Simon's case, a 40% signal strength is also a cause of
    retransmissions. I recommend that he try to get his signal strength up
    by repositioning his base station/AP.

    Andrew


    On Mar 7, 2004, at 10:08, Stuart Hickinbottom wrote:

    > I, too, have experienced this. At first I thought it might be a
    > problem in the encoded FLACs, but replaying them causes drops in
    > different places thus ruling out this possibility.
    >
    > I've checked the server and it's definitely not working hard either in
    > terms of network, CPU or disk activity.
    >
    > I have the Squeezebox operating over the wireless and so I wondered
    > whether that was a factor. The Squeezebox indicates about 60% signal
    > strength, which might be relevant, but if it wasn't able to stream
    > fast enough I would have expected a gradual drain being visible on the
    > buffer meter, which is not the case (it suddenly drops to zero once
    > the player goes silent).
    >
    > I've configured SlimServer to encode to MP3, via LAME, when streaming
    > FLACs over the internet. I don't experience this problem via this
    > channel, which makes me think that the FLAC decoding is working
    > perfectly and it's just something to do with the SlimServer/Squeezebox
    > route when playing FLACs.
    >
    > I too am using v5.1.1 with firmware 8, although I'm using a Linux
    > server.
    >
    > Hope that's enough information to be helpful. I'm not even sure I want
    > to encode everything as FLACs (192kbit MP3s sound nice enough to me),
    > so this isn't necessarily a big deal for me.
    >
    > Stuart
    >
    >
    > On Sun, 7 Mar 2004 10:31:23 -0000, Simon Turner <simon (AT) brighton (DOT) co.uk>
    > wrote:
    >
    >> Every now and again (av once per song perhaps) I'll get a second or
    >> two of
    >> silnec during a song. I have the Progress Indicator set to Show Buffer
    >> Fullness and can see that the buffer momentarily (and very instantly)
    >> drops
    >> from it's usual constant full position to zero.
    >>
    >> This does not happen when I play MP3s (even v. hi quality rips
    >> e.g --alt-extreme or 320CBR), It only happens when I play Flacs (I
    >> don't use
    >> any other formats).
    >>
    >> These are my particulars:
    >> Squeezebox. Firmware 8.
    >> SlimServer 5.1.1
    >> Windows XP
    >> Wireless signal strength 42%
    >>
    >> Condition of PC - RAM and processing power very underutilised. Minimal
    >> number of other services running.
    >>
    >> Any suggestions very welcome
    >> Thanks
    >> Simon Turner
    >> Brighton UK
    >>
    >>
    >>

  4. #4
    Stuart Hickinbottom
    Guest

    Squeezebox: Sound drop out with Flac files

    Thanks for the information; it might be true that the speed of the WLAN
    prevents effective streaming in such a raw format, but I would have
    expected to have been able to see the buffer draining down to an eventual
    drop-out point if this was the case. However, like Simon, I see the buffer
    permanently full until, suddenly, it drops to zero and the sound drops out
    for a few seconds.

    Perhaps this is a feature of the size of the buffer in the Squeezebox (I'm
    not sure how large it is) draining inbetween screen updates? I don't know
    how long the internal buffer would play raw data before draining the
    buffer when it is not being filled.

    Stuart

    On Sun, 7 Mar 2004 10:56:25 -0600, Andrew W. Donoho <awd (AT) ddg (DOT) com> wrote:

    > Simon and Stuart,
    >
    > FLAC, like AAC, decodes to either WAV or AIFF. This consumes a great
    > deal more bandwidth than an MP3 that is decoded in the SqueezeBox (1.5
    > Mb/s versus 320 kb/s for highest quality MP3).
    >
    > One thing you can do to minimize retransmissions on wireless is to
    > disable WEP security. WEP security can chew up a significant amount of
    > your approximately 6 Mb/s of real wireless bandwidth (upwards of 20% or
    > more). In Simon's case, a 40% signal strength is also a cause of
    > retransmissions. I recommend that he try to get his signal strength up
    > by repositioning his base station/AP.
    >
    > Andrew
    >
    >
    > On Mar 7, 2004, at 10:08, Stuart Hickinbottom wrote:
    >
    >> I, too, have experienced this. At first I thought it might be a
    >> problem in the encoded FLACs, but replaying them causes drops in
    >> different places thus ruling out this possibility.
    >>
    >> I've checked the server and it's definitely not working hard either in
    >> terms of network, CPU or disk activity.
    >>
    >> I have the Squeezebox operating over the wireless and so I wondered
    >> whether that was a factor. The Squeezebox indicates about 60% signal
    >> strength, which might be relevant, but if it wasn't able to stream
    >> fast enough I would have expected a gradual drain being visible on the
    >> buffer meter, which is not the case (it suddenly drops to zero once
    >> the player goes silent).
    >>
    >> I've configured SlimServer to encode to MP3, via LAME, when streaming
    >> FLACs over the internet. I don't experience this problem via this
    >> channel, which makes me think that the FLAC decoding is working
    >> perfectly and it's just something to do with the SlimServer/Squeezebox
    >> route when playing FLACs.
    >>
    >> I too am using v5.1.1 with firmware 8, although I'm using a Linux
    >> server.
    >>
    >> Hope that's enough information to be helpful. I'm not even sure I want
    >> to encode everything as FLACs (192kbit MP3s sound nice enough to me),
    >> so this isn't necessarily a big deal for me.
    >>
    >> Stuart
    >>
    >>
    >> On Sun, 7 Mar 2004 10:31:23 -0000, Simon Turner <simon (AT) brighton (DOT) co.uk>
    >> wrote:
    >>
    >>> Every now and again (av once per song perhaps) I'll get a second or
    >>> two of
    >>> silnec during a song. I have the Progress Indicator set to Show Buffer
    >>> Fullness and can see that the buffer momentarily (and very instantly)
    >>> drops
    >>> from it's usual constant full position to zero.
    >>>
    >>> This does not happen when I play MP3s (even v. hi quality rips
    >>> e.g --alt-extreme or 320CBR), It only happens when I play Flacs (I
    >>> don't use
    >>> any other formats).
    >>>
    >>> These are my particulars:
    >>> Squeezebox. Firmware 8.
    >>> SlimServer 5.1.1
    >>> Windows XP
    >>> Wireless signal strength 42%
    >>>
    >>> Condition of PC - RAM and processing power very underutilised. Minimal
    >>> number of other services running.
    >>>
    >>> Any suggestions very welcome
    >>> Thanks
    >>> Simon Turner
    >>> Brighton UK
    >>>
    >>>
    >>>

  5. #5
    Andrew W. Donoho
    Guest

    Priority Starvation (was: Squeezebox: Sound drop out withFlac files)

    On Mar 7, 2004, at 11:28, Stuart Hickinbottom wrote:

    > Thanks for the information; it might be true that the speed of the
    > WLAN prevents effective streaming in such a raw format, but I would
    > have expected to have been able to see the buffer draining down to an
    > eventual drop-out point if this was the case. However, like Simon, I
    > see the buffer permanently full until, suddenly, it drops to zero and
    > the sound drops out for a few seconds.
    >
    > Perhaps this is a feature of the size of the buffer in the Squeezebox
    > (I'm not sure how large it is) draining inbetween screen updates? I
    > don't know how long the internal buffer would play raw data before
    > draining the buffer when it is not being filled.



    I have been able to reproduce the dropouts with my wireline system. It
    appears to me that slimserver.pl on Linux is not launching child
    processes with the same execution priority as itself. For example,
    slimserver.pl is running with a priority of 15. While faad, the AAC
    decoder on Linux, is running at a priority of 25 (the lower the number
    the higher the execution priority). I would hypothesize that faad is
    getting starved for execution time when the system is under sustained
    load. I can reproduce this behavior almost at will by kicking of a
    Bayes database reconfiguration for anti-SPAM.

    For the record, my system is a RH 9 system with dual 450 MHz Celeron
    processors, 512 MBof DRAM and 140 GB of disk using 100BaseT into a
    commercial D-Link switch to connect tot he SqueezeBox over 10BaseT
    wireline ethernet. I am also running the 5.1.1 release of SlimServer.

    Andrew

    ____________________________________
    Andrew W. Donoho
    awd (AT) DDG (DOT) com, PGP Key ID: 0x81D0F250
    +1 (512) 453-6652 (o), +1 (512) 750-7596 (m)

  6. #6
    Ron Thigpen
    Guest

    Priority Starvation

    Andrew W. Donoho wrote:

    > I have been able to reproduce the dropouts with my wireline system. It
    > appears to me that slimserver.pl on Linux is not launching child
    > processes with the same execution priority as itself. For example,
    > slimserver.pl is running with a priority of 15. While faad, the AAC
    > decoder on Linux, is running at a priority of 25 (the lower the number
    > the higher the execution priority). I would hypothesize that faad is
    > getting starved for execution time when the system is under sustained
    > load.



    Andrew,

    You may want to file a bug report/enhancement request on this issue.

    see:
    <http://bugs.slimdevices.com/>

    --rt

Posting Permissions

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