PDA

View Full Version : Squeezebox: Sound drop out with Flac files



Simon Turner
2004-03-07, 03:31
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

Stuart Hickinbottom
2004-03-07, 09:08
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
>
>
>

Andrew W. Donoho
2004-03-07, 09:56
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
>>
>>
>>

Stuart Hickinbottom
2004-03-07, 10:28
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
>>>
>>>
>>>

Andrew W. Donoho
2004-03-07, 22:51
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)

Ron Thigpen
2004-03-08, 09:24
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