PDA

View Full Version : Uncompressed audio dropouts: some progress



Joe Moon
2004-12-25, 14:49
Like some others, I've been experiencing frequent dropouts when playing
uncompressed audio over my wired squeezebox.
After some troubleshooting, here's what I've noticed:
1. Songs with long titles (often classical pieces) have more dropouts
2. Turning on the "buffer fullness" display (1) shows a full buffer
right up to the dropouts, and (2) makes the dropout problem worse.
3. Turning on debugging flags (most notably: d_slimproto_v) shows
SlimServer sending a large number (>100) of consecutive vfdc frames,
which I gather are updates to the display.
4. After the barrage of display updates, the squeezebox closes the
socket connection. During the few seconds while the connection is
re-established, the buffer empties and the audio drops out.

It looks like the squeezebox is being overwhelmed by the display
updates caused by scrolling the long titles, updating the "buffer
fullness", etc. Doing the following helped a *lot*:
1. Under "Player Settings", set the "Now Playing" information to
"Nothing" (turns off progress bars, etc.)
2. Under "Player Settings/Display", set the "Scroll Pause" to some
large value (for both single- and double-line), to effectively turn off
scrolling. I'm using 900 (15 minutes).

I'd be interested in hearing whether this works for others experiencing
the dropout problem.
--Joe

P.S., I'm running SlimServer 5.4.0, firmware v.40, Mac OS X (10.3.5) on
a dedicated G3/450/768M.

Joe Moon
2005-01-04, 20:19
As a follow-up to my original posting, I thought I'd add one curious
tidbit -- there is some kind of strange issue with long track names.
Even with the scrolling turned off, songs with long names -- too long
to fit on the SB display -- give me brief "lost connection" messages,
and, very occasionally, audio dropouts. (The connection is usually
re-established immediately, before the buffer empties, as long as
scrolling is turned off.)

I was surprised to see (unless I'm misreading the code) that the
SlimServer "micromanages" the text scrolling on the SB, but I'm
*really* surprised that there is still some negative effect from long
track names. Anyone have an explanation for this?

Still interested in hearing whether disabling scrolling helps any of
the others who are having dropouts.
--Joe

> Like some others, I've been experiencing frequent dropouts when
> playing uncompressed audio over my wired squeezebox.
> After some troubleshooting, here's what I've noticed:
> 1. Songs with long titles (often classical pieces) have more dropouts
> 2. Turning on the "buffer fullness" display (1) shows a full buffer
> right up to the dropouts, and (2) makes the dropout problem worse.
> 3. Turning on debugging flags (most notably: d_slimproto_v) shows
> SlimServer sending a large number (>100) of consecutive vfdc frames,
> which I gather are updates to the display.
> 4. After the barrage of display updates, the squeezebox closes the
> socket connection. During the few seconds while the connection is
> re-established, the buffer empties and the audio drops out.
>
> It looks like the squeezebox is being overwhelmed by the display
> updates caused by scrolling the long titles, updating the "buffer
> fullness", etc. Doing the following helped a *lot*:
> 1. Under "Player Settings", set the "Now Playing" information to
> "Nothing" (turns off progress bars, etc.)
> 2. Under "Player Settings/Display", set the "Scroll Pause" to some
> large value (for both single- and double-line), to effectively turn
> off scrolling. I'm using 900 (15 minutes).
>
> I'd be interested in hearing whether this works for others
> experiencing the dropout problem.
> --Joe
>
> P.S., I'm running SlimServer 5.4.0, firmware v.40, Mac OS X (10.3.5)
> on a dedicated G3/450/768M.
>
>

gareth hughes
2005-01-05, 05:40
I've followed your suggestions and haven't had a dropout since. However its not
been on much so will report back later. Fingers are crossed.





Quoting Joe Moon <joe (AT) moonzone (DOT) net>:

> As a follow-up to my original posting, I thought I'd add one curious
> tidbit -- there is some kind of strange issue with long track names.
> Even with the scrolling turned off, songs with long names -- too long
> to fit on the SB display -- give me brief "lost connection" messages,
> and, very occasionally, audio dropouts. (The connection is usually
> re-established immediately, before the buffer empties, as long as
> scrolling is turned off.)
>
> I was surprised to see (unless I'm misreading the code) that the
> SlimServer "micromanages" the text scrolling on the SB, but I'm
> *really* surprised that there is still some negative effect from long
> track names. Anyone have an explanation for this?
>
> Still interested in hearing whether disabling scrolling helps any of
> the others who are having dropouts.
> --Joe
>
> > Like some others, I've been experiencing frequent dropouts when
> > playing uncompressed audio over my wired squeezebox.
> > After some troubleshooting, here's what I've noticed:
> > 1. Songs with long titles (often classical pieces) have more dropouts
> > 2. Turning on the "buffer fullness" display (1) shows a full buffer
> > right up to the dropouts, and (2) makes the dropout problem worse.
> > 3. Turning on debugging flags (most notably: d_slimproto_v) shows
> > SlimServer sending a large number (>100) of consecutive vfdc frames,
> > which I gather are updates to the display.
> > 4. After the barrage of display updates, the squeezebox closes the
> > socket connection. During the few seconds while the connection is
> > re-established, the buffer empties and the audio drops out.
> >
> > It looks like the squeezebox is being overwhelmed by the display
> > updates caused by scrolling the long titles, updating the "buffer
> > fullness", etc. Doing the following helped a *lot*:
> > 1. Under "Player Settings", set the "Now Playing" information to
> > "Nothing" (turns off progress bars, etc.)
> > 2. Under "Player Settings/Display", set the "Scroll Pause" to some
> > large value (for both single- and double-line), to effectively turn
> > off scrolling. I'm using 900 (15 minutes).
> >
> > I'd be interested in hearing whether this works for others
> > experiencing the dropout problem.
> > --Joe
> >
> > P.S., I'm running SlimServer 5.4.0, firmware v.40, Mac OS X (10.3.5)
> > on a dedicated G3/450/768M.
> >
> >