PDA

View Full Version : Diagnosing drop-outs



Christopher Farley
2004-01-09, 14:12
I am a new owner of a squeezebox. I am very happy with it so far.

I *only* listen to uncompressed streams (never tried an MP3, actually).
I get occasional drop-outs. Nothing severe, but maybe 1-2 per hour.

I use WiFi (DLink 2.4 GHz Access Point, 128 bit WEP). The squeezebox
reports a signal strength of 65-70%.

My server is running on a Gentoo Linux box (900 MHz C3 processor,
256 Megs of RAM, one single 7200 RPM ATA-100 HD). The machine is
not (yet) a dedicated server, and sometimes there is some other disk
activity and swapping going on.

I am using the coax digital out of the squeezebox, and feeding it into a
DA converter.

Are there any tools (or tricks) to diagnose the cause of the
drop-outs? For example, it would be nice if the squeezebox could
log a buffer underrun, or if the server had some information on its
performance. Or perhaps my wireless signal strength is not good
enough to listen to PCM audio. Or maybe some device in my house is
causing intermittent RF interference (it'd be nice if the squeezebox
could log its signal strength during a dropout). I've also wondered
if the digital out of the squeezebox has a lot of jitter, or if my
coax cable is bad. During the dropouts, the DA converter totally
loses the signal, which I assume is normal...

I have several computers, and I ran the slimserver with some
additional RAM --- 512 MB. This improved the situation, but I
still got a dropout during several hours of listening. There was
minimal (but not 0) swap being used when I checked the server.

My best guess is that some high priority program is forcing the
slimserver to wait for an excessive period of time. I have never
tried running the slimserver at a very high priority, but that's
something I may do if this continues...

My server is built primarily for low power consumption and quietness.
It's a MiniITX motherboard, which has a C3 CPU (only 64 KB of onboard
cache). It's no Athlon, but I can't imagine this machine is
too slow to run a slimserver.

Is my goal of zero dropouts realistic over WiFi? I'm going to start
building a dedicated server with multiple hard drives (one for music and
one for the OS/swap), but it seems like I should be able to achieve
high performance even on my current setup.

--
Christopher Farley
www.northernbrewer.com

Christopher Farley
2004-01-09, 18:38
Jason Holtzapple (jasonholtzapple (AT) yahoo (DOT) com) wrote:

> --- Christopher Farley <chris (AT) northernbrewer (DOT) com> wrote:
> > Are there any tools (or tricks) to diagnose the cause of the
> > drop-outs?
>
> If you're using a recent nightly build, you can change the
> progress bar into a buffer indicator. The setting is in
> the Performance section of the server preferences.

Awesome. I'll take a look. Somebody said they thought the squeezebox
buffer was about 8 seconds for MP3s... I'm *real* curious what it
is with an uncompressed stream, because I have a hard time believing
that something is forcing the slimserver to sleep for more than a
second or two... Serving up audio is not a real demanding task.

What about my WiFi signal strength? Is 65-70% acceptable? Is there some
kind of RF event that could periodically interfere with the signal?
I could try and run the squeezebox on a wire for a while to see if that
helps...

> > My best guess is that some high priority program is forcing the
> > slimserver to wait for an excessive period of time. I have never
> > tried running the slimserver at a very high priority, but that's
> > something I may do if this continues...
>
> It's worth a try as part of your troubleshooting process.
> Some unix systems will automatically lower the priority
> of a daemon process to '4.' It is worth checking to see
> if that's the case and at least bumping it back up to '0.'

I'm actually not running the server as a daemon. I manually start
the server with `./slimserver.pl`... But I will definitely mess around
with the priority, and even try running it at -20 for a while...

> > My server is built primarily for low power consumption and quietness.
> > It's a MiniITX motherboard, which has a C3 CPU (only 64 KB of onboard
> > cache). It's no Athlon, but I can't imagine this machine is
> > too slow to run a slimserver.
>
> I run 2 slimp3s and a squeezebox from a similar setup
> with no problems. 800 MHz, 512 Mb RAM.

I am quite confident that the increasing the RAM to 512 MB really
helped. That's why I think that the dropouts occur while the
machine is paging stuff in/out of swap.

> > Is my goal of zero dropouts realistic over WiFi? I'm going to start
> > building a dedicated server with multiple hard drives (one for music and
> > one for the OS/swap), but it seems like I should be able to achieve
> > high performance even on my current setup.
>
> Is there a compelling reason why you're using
> uncompressed audio? If you compress with FLAC or
> some other lossless encoder you'll reduce the amount
> of transmitted data and disk space usage by about 50%
> with a very modest cost in CPU usage and no
> reduction in quality.

My files are actually FLAC files, but since they are decompressed
before being sent to the squeezebox, I describe it as an "uncompressed
stream".

....in addition to taking up less space, FLAC allows you to tag!

--
Christopher Farley
www.northernbrewer.com

kdf
2004-01-09, 19:21
Quoting Christopher Farley <chris (AT) northernbrewer (DOT) com>:

> Jason Holtzapple (jasonholtzapple (AT) yahoo (DOT) com) wrote:

> Awesome. I'll take a look. Somebody said they thought the squeezebox
> buffer was about 8 seconds for MP3s... I'm *real* curious what it
> is with an uncompressed stream, because I have a hard time believing
> that something is forcing the slimserver to sleep for more than a
> second or two... Serving up audio is not a real demanding task.

that was me, and its the slimp3 that has 8 seconds. Squeezebox should be more,
but I dont know offhand how much.
-kdf

Christopher Farley
2004-01-11, 00:27
James Dunn (james.dunn (AT) hedgehog-house (DOT) co.uk) wrote:

> I just raised the priority on my server. I've
> suffered no-dropouts since.

With uncompressed streams, the likelihood of buffer underruns is
obviously greater. The 2MB buffer on the squeezebox is good for maybe 2
seconds of uncompressed audio.

It would be awesome if the squeezebox could put an entry in an event log
every time the buffer ran dry. This would be really useful for network
tuning -- especially for those of us playing uncompressed streams. I'd
love to set my squeezebox to play music all night, and then get up in
the morning to see if there were any dropouts.

--
Christopher Farley
www.northernbrewer.com