PDA

View Full Version : Slim Devices SB2 disappointment & SB for sale.



PAUL WILLIAMSON
2005-03-24, 06:40
>>> karn (AT) ka9q (DOT) net 03/23/05 10:40 PM >>>
> The problem with the existing server, just as you point out,
> is that the real-time and non-real-time server functions are
> bundled into the same tasks and threads, and insufficient
> attention has been paid to meeting real-time-critical playback
> requirements. Yes, the bigger buffer in the SB2 will definitely
> help (I have one on order) but I disagree that it's the only
> way or even the best way to solve the problem.

With all this information, how do you explain that I've got a
wired squezeboxG and a 100mb switched environment,
all FLACs, that play all day long with no skips or dropouts,
all powered from a lowly PIII 800Mhz box with 512mb
of ram and 4x250gb drives, all LVM'd together for about
1tb of space? Your machine is definitely got more "oomph"
than mine, yet I've got no problems.

I had a party a couple weeks ago, and using the latest nightly
of the 5.4.1 branch (don't remember the day - maybe 3/11?)
without a single problem.

Paul

Mitch Harding
2005-03-24, 09:13
I imagine he explains it by saying that each case is unique. It's
completely possible that even two people with comparable setups would
have different experiences.

On Thu, 24 Mar 2005 08:40:29 -0500, PAUL WILLIAMSON
<pwilliamson (AT) mandtbank (DOT) com> wrote:
> >>> karn (AT) ka9q (DOT) net 03/23/05 10:40 PM >>>
> > The problem with the existing server, just as you point out,
> > is that the real-time and non-real-time server functions are
> > bundled into the same tasks and threads, and insufficient
> > attention has been paid to meeting real-time-critical playback
> > requirements. Yes, the bigger buffer in the SB2 will definitely
> > help (I have one on order) but I disagree that it's the only
> > way or even the best way to solve the problem.
>
> With all this information, how do you explain that I've got a
> wired squezeboxG and a 100mb switched environment,
> all FLACs, that play all day long with no skips or dropouts,
> all powered from a lowly PIII 800Mhz box with 512mb
> of ram and 4x250gb drives, all LVM'd together for about
> 1tb of space? Your machine is definitely got more "oomph"
> than mine, yet I've got no problems.
>
> I had a party a couple weeks ago, and using the latest nightly
> of the 5.4.1 branch (don't remember the day - maybe 3/11?)
> without a single problem.
>
> Paul
>
>

vidurapparao
2005-03-24, 11:06
That's very true and especially so at the junction of digital music,
wireless networking, and cross-platform support. The level of quality of
our software and hardware in the end is not determined just by the
amount of testing we do in-house, but is a function of the number of
real-world users who give us feedback. That's why this list and the
community at large are invaluable to our development process.

I understand the frustration of those who see problems in the field,
especially if they have seemingly ideal setups. This is consumer
electronics - it should just work. We're continuing to work towards that
goal and for the majority of our customers, it does just work. In the
meantime, we appreciate any and all feedback (though the type with
details about hardware, OS, networking setups, and steps to recreate a
problem is the most useful). :-)

Mitch Harding wrote:

>I imagine he explains it by saying that each case is unique. It's
>completely possible that even two people with comparable setups would
>have different experiences.
>
>On Thu, 24 Mar 2005 08:40:29 -0500, PAUL WILLIAMSON
><pwilliamson (AT) mandtbank (DOT) com> wrote:
>
>
>>>>>karn (AT) ka9q (DOT) net 03/23/05 10:40 PM >>>
>>>>>
>>>>>
>>>The problem with the existing server, just as you point out,
>>>is that the real-time and non-real-time server functions are
>>>bundled into the same tasks and threads, and insufficient
>>>attention has been paid to meeting real-time-critical playback
>>>requirements. Yes, the bigger buffer in the SB2 will definitely
>>>help (I have one on order) but I disagree that it's the only
>>>way or even the best way to solve the problem.
>>>
>>>
>>With all this information, how do you explain that I've got a
>>wired squezeboxG and a 100mb switched environment,
>>all FLACs, that play all day long with no skips or dropouts,
>>all powered from a lowly PIII 800Mhz box with 512mb
>>of ram and 4x250gb drives, all LVM'd together for about
>>1tb of space? Your machine is definitely got more "oomph"
>>than mine, yet I've got no problems.
>>
>>I had a party a couple weeks ago, and using the latest nightly
>>of the 5.4.1 branch (don't remember the day - maybe 3/11?)
>>without a single problem.
>>
>>Paul
>>
>>

Phil Karn
2005-03-30, 02:42
PAUL WILLIAMSON wrote:

> With all this information, how do you explain that I've got a
> wired squezeboxG and a 100mb switched environment,
> all FLACs, that play all day long with no skips or dropouts,
> all powered from a lowly PIII 800Mhz box with 512mb
> of ram and 4x250gb drives, all LVM'd together for about
> 1tb of space? Your machine is definitely got more "oomph"
> than mine, yet I've got no problems.
>
> I had a party a couple weeks ago, and using the latest nightly
> of the 5.4.1 branch (don't remember the day - maybe 3/11?)
> without a single problem.

Well, I can think of a couple of explanations. For one thing, I was
running 5.4.0, not 5.4.1, until I switched just now to 6.0.0 to make my
SB2 work.

Another possibility may be that I expect to do other substantial things
with my Linux box besides running Slimserver. That's why careful
attention to thread prioritization is important. If the machine never
has to do anything else, priority settings don't matter much.

Phil

Jack Coates
2005-03-30, 08:09
Phil Karn wrote:
> PAUL WILLIAMSON wrote:
>
>> With all this information, how do you explain that I've got a wired
>> squezeboxG and a 100mb switched environment, all FLACs, that play all
>> day long with no skips or dropouts, all powered from a lowly PIII
>> 800Mhz box with 512mb of ram and 4x250gb drives, all LVM'd together
>> for about 1tb of space? Your machine is definitely got more "oomph"
>> than mine, yet I've got no problems.
>> I had a party a couple weeks ago, and using the latest nightly of the
>> 5.4.1 branch (don't remember the day - maybe 3/11?) without a single
>> problem.
>
>
> Well, I can think of a couple of explanations. For one thing, I was
> running 5.4.0, not 5.4.1, until I switched just now to 6.0.0 to make my
> SB2 work.
>
> Another possibility may be that I expect to do other substantial things
> with my Linux box besides running Slimserver. That's why careful
> attention to thread prioritization is important. If the machine never
> has to do anything else, priority settings don't matter much.
>
> Phil

heh... my machine is doing a lot more than yours and I never have skips.
The key issue here is streaming FLAC, IMHO, exacerbated by the size of
your library. My ears aren't good enough to tell the difference, so I
play MP3 and a few OGGs. I wonder if you still see dropouts when
transcoding? I bet that even with the increased CPU load of running the
lame process, it would still come out performing better than you have now.

--
Jack at Monkeynoodle dot Org: It's a Scientific Venture...
Riding the Emergency Third Rail Power Trip since 1996!

Phil Karn
2005-03-30, 18:44
Jack Coates wrote:

> heh... my machine is doing a lot more than yours and I never have skips.
> The key issue here is streaming FLAC, IMHO, exacerbated by the size of
> your library. My ears aren't good enough to tell the difference, so I
> play MP3 and a few OGGs. I wonder if you still see dropouts when
> transcoding? I bet that even with the increased CPU load of running the
> lame process, it would still come out performing better than you have now.
>

Well yes -- I totally agree that there's a *big* difference between
streaming PCM (WAV, FLAC, Ogg and AAC) and MP3. I don't have any problem
streaming MP3 either. The data rate over the LAN for MP3 is so much
lower than raw PCM (320 kb/s max vs about 1411 kb/s) that the Slimserver
has no trouble keeping the Squeezebox's fixed-size buffer from running
completely dry in MP3 mode.

My playback skips occur only when I play a file format that has to be
transcoded on the server to raw, high speed PCM. Then the fixed-size SB
buffer drains much more quickly, and sometimes the Slimserver doesn't
refill it before it empties completely. Then I hear a skip.

You're right, my skips *would* almost certainly go away if I transcoded
everything to MP3 over the LAN. And yes, I have enough server CPU cycles
to do that in real time. But that's a *kludge*, and I shouldn't have to
resort to kludges. The Squeezebox is advertised as being able to stream
raw PCM over a 100 Mb/s Ethernet LAN in real time, and that's just what
I want it to do. All it would take is some careful attention paid to
proper task/thread structuring and prioritization within the Slimserver
package. I've bought three Squeezeboxes so far, and I paid a tidy sum of
money for them. Why is it somehow unreasonable to expect them to perform
as advertized?

--Phil

Jack Coates
2005-03-30, 20:52
Phil Karn wrote:
....
> You're right, my skips *would* almost certainly go away if I transcoded
> everything to MP3 over the LAN. And yes, I have enough server CPU cycles
> to do that in real time. But that's a *kludge*, and I shouldn't have to
> resort to kludges. The Squeezebox is advertised as being able to stream
> raw PCM over a 100 Mb/s Ethernet LAN in real time, and that's just what
> I want it to do. All it would take is some careful attention paid to
> proper task/thread structuring and prioritization within the Slimserver
> package. I've bought three Squeezeboxes so far, and I paid a tidy sum of
> money for them. Why is it somehow unreasonable to expect them to perform
> as advertized?
>
> --Phil

No, your requests aren't unreasonable from a customer standpoint, though
I can't help but think that you do seem informed enough to have thought
the issues through and had an idea what to expect beforehand. I do think
that Slim Devices could have done a better job of what in my day job we
call "setting expectations"... that is, gently introducing reality into
the discussion without dispelling too much of the glow. As I'm sure
you're aware, "some careful attention paid to proper task/thread
structuring and prioritization within the Slimserver package" is easier
said than done. Plenty of people have recognized that it would help, but
no one has produced any code. I certainly don't have the chops or time
to do it.

Yes, I am trotting out the typical open source defence of "if you're not
happy, patch it"... well, Slimserver is open source and plenty of its
functionality has been provided by non-SDI folks, so the defence
certainly applies. Sure, it'd be great if you could take the entire
bullet list of features and have them all implemented in a single
product... any product, really...

--
Jack at Monkeynoodle dot Org: It's a Scientific Venture...
Riding the Emergency Third Rail Power Trip since 1996!

seanadams
2005-03-30, 22:35
Phil,

I don't have a magic bullet for this.

When I started designing the Squeezebox1 hardware in 2002, I fully
realized that an enormous buffer would be desirable. However, the
architecture (which was chosen based on a long list of goals including
ethernet/wireless capability, ability to drive a graphic VFD, OS
performance, etc) unfortunately did not have an SDRAM interface, only
SRAM, which meant that a very large (several MB) buffer would not be
possible. Dean and I did a great deal of testing and never saw any
problems on wired ethernet under any OS. On wireless networks there
were some issues at first, which were quickly eliminated, most of them
anyway, with some careful tuning of the TCP stack.

What we found was that in the real world there were still a few
problems. I spent many weeks studying packet dumps and optimizing TCP
(http://www.seanadams.com/ip2k), testing on Windows, Mac, and Linux,
getting feedback from customers, and making improvements.

It is no secret that a bigger buffer would be nice - in fact I think
this request has been in our public bug database since its inception.
Unfortunately the only way we can make the buffer larger is to make new
hardware with a larger buffer, which is exactly what we've done.
Optimizing streaming performance is still an active goal.

PCM streaming on Squeezebox1, even with its 256K buffer capacity, works
as advertised in nearly all environments, unlike my car which can only
reach its advertised top speed on less than 0.01% of the road surface
in the USA. I realize this is a retarded analogy and not a kind
response but consider this: we are more open than any hardware company
(that I know of) in terms of admitting where there's room for
improvement (bugs.slimdevices.com). We view this information not as a
liability, but as priceless guidance in how to make our products
better.

Certain issues are simply not addressable in software (802.11g support,
as another example). For those issues we develop new hardware.

Finally, as protection we provide a 30-day no questions asked return
period. If the product doesn't work the way you want it to, or even if
you just have a change of heart for some reason, we'll take it back.
During those 30 days if you have some problem we will do everything we
can to resolve it for you. We'd prefer to fix it, but you can send it
back no matter what. This isn't a just some bullshit buying prod like
on the late-night infomercials - we actually honor this policy. It
protects you if the product isn't what you thought it was, it protects
you if the price plummets, and it protects you if the product doesn't
work. We get very few returns.

I don't know what else to say - we vastly improved PCM streaming
performance by adding a huge buffer, adding 802.11g wireles support,
and adding lossless compression. At the same time we added a whole slew
of features in SlimServer 6 which improve SLIMP3, a product which we
began selling out of my garage in 2001, and of which we have not sold a
single unit since 2003. I realize that these are not huge time scales
in the grand scheme of things but still, I'm lucky to get free bug
fixes or free feature additions for anything after six months or so.
We're doing everything we can Phil.

Best wishes,
Sean


On Mar 30, 2005, at 5:44 PM, Phil Karn wrote:

> Jack Coates wrote:
>
>> heh... my machine is doing a lot more than yours and I never have
>> skips. The key issue here is streaming FLAC, IMHO, exacerbated by the
>> size of your library. My ears aren't good enough to tell the
>> difference, so I play MP3 and a few OGGs. I wonder if you still see
>> dropouts when transcoding? I bet that even with the increased CPU
>> load of running the lame process, it would still come out performing
>> better than you have now.
>
> Well yes -- I totally agree that there's a *big* difference between
> streaming PCM (WAV, FLAC, Ogg and AAC) and MP3. I don't have any
> problem streaming MP3 either. The data rate over the LAN for MP3 is so
> much lower than raw PCM (320 kb/s max vs about 1411 kb/s) that the
> Slimserver has no trouble keeping the Squeezebox's fixed-size buffer
> from running completely dry in MP3 mode.
>
> My playback skips occur only when I play a file format that has to be
> transcoded on the server to raw, high speed PCM. Then the fixed-size
> SB buffer drains much more quickly, and sometimes the Slimserver
> doesn't refill it before it empties completely. Then I hear a skip.
>
> You're right, my skips *would* almost certainly go away if I
> transcoded everything to MP3 over the LAN. And yes, I have enough
> server CPU cycles to do that in real time. But that's a *kludge*, and
> I shouldn't have to resort to kludges. The Squeezebox is advertised as
> being able to stream raw PCM over a 100 Mb/s Ethernet LAN in real
> time, and that's just what I want it to do. All it would take is some
> careful attention paid to proper task/thread structuring and
> prioritization within the Slimserver package. I've bought three
> Squeezeboxes so far, and I paid a tidy sum of money for them. Why is
> it somehow unreasonable to expect them to perform as advertized?
>
> --Phil
>

Daniel Cohen
2005-03-31, 00:23
On 30/3/05 at 9:35 pm -0800, Sean Adams wrote
>
>Finally, as protection we provide a 30-day no questions asked return
>period. If the product doesn't work the way you want it to, or even
>if you just have a change of heart for some reason, we'll take it
>back. During those 30 days if you have some problem we will do
>everything we can to resolve it for you. We'd prefer to fix it, but
>you can send it back no matter what. This isn't a just some bullshit
>buying prod like on the late-night infomercials - we actually honor
>this policy. It protects you if the product isn't what you thought
>it was, it protects you if the price plummets, and it protects you
>if the product doesn't work. We get very few returns.

A great policy, and I'm glad that you get very few returns.

Out of curiosity (no more), what's the situation for those of us in
the UK (or ohter countries outside North America) if we buy from a
local supplier.
--
Daniel Cohen

seanadams
2005-03-31, 09:04
On Mar 30, 2005, at 11:23 PM, Daniel Cohen wrote:

> On 30/3/05 at 9:35 pm -0800, Sean Adams wrote
>>
>> Finally, as protection we provide a 30-day no questions asked return
>> period. If the product doesn't work the way you want it to, or even
>> if you just have a change of heart for some reason, we'll take it
>> back. During those 30 days if you have some problem we will do
>> everything we can to resolve it for you. We'd prefer to fix it, but
>> you can send it back no matter what. This isn't a just some bullshit
>> buying prod like on the late-night infomercials - we actually honor
>> this policy. It protects you if the product isn't what you thought it
>> was, it protects you if the price plummets, and it protects you if
>> the product doesn't work. We get very few returns.
>
> A great policy, and I'm glad that you get very few returns.
>
> Out of curiosity (no more), what's the situation for those of us in
> the UK (or ohter countries outside North America) if we buy from a
> local supplier.

It depends on the supplier, but I think they all have something like
this too.

Robin Bowes
2005-03-31, 14:55
Phil Karn wrote:
> The Squeezebox is advertised as being able to stream
> raw PCM over a 100 Mb/s Ethernet LAN in real time, and that's just what
> I want it to do.

Phil,

Can you show me where this claim is made? I'd be very surprised if this
is true. For a start, the wired port on the SB1 is only 10MB/s (I can't
find a spec. sheet to confirm this, but the last point here [1] says:

- faster 100Mbps wired ethernet interface

[1] http://www.slimdevices.com/su_faq.html#about2-difference

I've got a wireless SB1, and until recently, I had no problems with
dropouts caused by network bandwidth (I too play flac files decoded on
the server and streamed as raw PCM).

In my new place, the WAP is further away from the SB and the signal
level was low (20% - 40%) and I found I often got dropouts.

I then managed to break the SB aerial so had to get a new one. I picked
up one of these [2] and fitted it today. I'm now getting signal strength
of a solid 58% and my flacs now play perfectly again.

[2]
http://www.broadbandbuyer.co.uk/Shop/ShopDetail.asp?ShopGroupID=3&CategoryID=32&ProductID=260

I agree with the point you make about threading and making the streaming
part of slimserver work better, but I don't think the SB or slimserver
is particularly at fault in causing your dropouts - there must be
something in your environment that is causing the problem. Maybe the
port you've got the SB plugged into is not auto-detecting the 10Base-T
link? Have you checked?

R.
--
http://robinbowes.com

Phil Karn
2005-04-07, 23:22
Sean Adams wrote:

> When I started designing the Squeezebox1 hardware in 2002, I fully
> realized that an enormous buffer would be desirable. However, the
> architecture (which was chosen based on a long list of goals including
> ethernet/wireless capability, ability to drive a graphic VFD, OS
> performance, etc) unfortunately did not have an SDRAM interface, only
> SRAM, which meant that a very large (several MB) buffer would not be
> possible. Dean and I did a great deal of testing and never saw any
> problems on wired ethernet under any OS. On wireless networks there were
> some issues at first, which were quickly eliminated, most of them
> anyway, with some careful tuning of the TCP stack.

I understand your design constraints. Memory is nice, but it can also be
expensive and you don't want your box costing more than it really has
to. That's quite reasonable.

> What we found was that in the real world there were still a few
> problems. I spent many weeks studying packet dumps and optimizing TCP
> (http://www.seanadams.com/ip2k), testing on Windows, Mac, and Linux,
> getting feedback from customers, and making improvements.

Yup. Many stacks do have glitches, although I think the later Linux
stacks behave very well, especially when the entire path is just a few
high speed Ethernet hubs. A bigger issue, I think, are the OS and disk
scheduling algorithms.

> It is no secret that a bigger buffer would be nice - in fact I think
> this request has been in our public bug database since its inception.
> Unfortunately the only way we can make the buffer larger is to make new
> hardware with a larger buffer, which is exactly what we've done.
> Optimizing streaming performance is still an active goal.

But I don't think that buffer *has* to be huge. If it does, then that's
a symptom of brokenness someplace else, specifically in the server and
the way it is treated by the operating system on which it runs.

> PCM streaming on Squeezebox1, even with its 256K buffer capacity, works
> as advertised in nearly all environments, unlike my car which can only
> reach its advertised top speed on less than 0.01% of the road surface in
> the USA. I realize this is a retarded analogy and not a kind response
> but consider this: we are more open than any hardware company (that I
> know of) in terms of admitting where there's room for improvement
> (bugs.slimdevices.com). We view this information not as a liability, but
> as priceless guidance in how to make our products better.

Um, I assume you didn't mean that as a serious analogy! A better analogy
would be to the per-mile probability of my car suddenly and without
warning, seizing up and stopping dead in the middle of the freeway.
Then, after a few seconds, the tires screech and it suddenly lurches
back up to 65 mph just as unexpectedly. :-)

> Certain issues are simply not addressable in software (802.11g support,
> as another example). For those issues we develop new hardware.

Understood. Since you advertised those hardware limitations, I can't
complain. Your transcoding scheme to optionally limit the network bit
rate to something it can support was a very nice touch.

> Finally, as protection we provide a 30-day no questions asked return
> period. If the product doesn't work the way you want it to, or even if
> you just have a change of heart for some reason, we'll take it back.

Well, that's problematical when the problem is in software, not
hardware. Again, I have no complaints about the Squeezebox hardware,
either version 1 or version 2. If the hardware were broken, mis designed
or otherwise unusable, then it would be easy to decide to return it in
the 30 day period.

But the hardware is all fine; all of the problems I've encountered have
been in server software, and that makes returning the unit a much harder
call. You never know whether a given problem that you consider really
serious will be fixed tomorrow or next week or next month or next year.
Believing strongly as I do in the power of open source, I have decided
to keep all three Squeezeboxes and wait for the software to improve. And
that can be frustrating. Yes, I could roll up my sleeves and jump in and
hack the code myself, but the Slimserver package is already a very large
chunk of code that presents a dauntingly steep learning curve to anyone
who wants to modify it. Confronted by it, I'd be strongly tempted to
start over from scratch, or by adapting existing, mature mechanisms that
I already know to work well (e.g., adapting the standard printer
spooling system to manage queues and play lists for a Squeezebox.)

> I don't know what else to say - we vastly improved PCM streaming
> performance by adding a huge buffer, adding 802.11g wireles support, and
> adding lossless compression. At the same time we added a whole slew of
> features in SlimServer 6 which improve SLIMP3, a product which we began
> selling out of my garage in 2001, and of which we have not sold a single
> unit since 2003. I realize that these are not huge time scales in the
> grand scheme of things but still, I'm lucky to get free bug fixes or
> free feature additions for anything after six months or so. We're doing
> everything we can Phil.

I know you are, and I still think you have an excellent product with
enormous potential. That's why I don't want to just give up on it and
ask for my money back. It's just that sometimes I think the priorities
of those working on the SlimServer code are a little odd. I cannot be
the only one who thinks various bells and whistles like a dozen and a
half web skins and crawling news feeds and audio visualizers simply
aren't as important as ensuring the basic functionality of the system
(playing music) and making it as reliable, available and portable as
possible.

Phil

Phil Karn
2005-04-08, 00:02
Robin Bowes wrote:

> Can you show me where this claim is made? I'd be very surprised if this
> is true. For a start, the wired port on the SB1 is only 10MB/s (I can't
> find a spec. sheet to confirm this, but the last point here [1] says:
>
> - faster 100Mbps wired ethernet interface

I do believe you're right; it's 10 Mb/s on the SB1. I checked it by
plugging it directly into my PowerBook and looking at the interface
settings, and also by plugging it into a different hub that indicates
link speed on the LEDs.

But this doesn't really matter. A raw, uncompressed PCM audio stream
still takes up only 14% of a 10 Mb/s Ethernet port, so there's no reason
it should cause any kind of playback interruption unless it's used on an
ancient 10 Mb/s non-switched hub with lots of contending traffic. I got
rid of all my hubs years ago. Every network port is switched and
supports full duplex up to 100 or 1000 Mb/s, depending on the specific
switch. The Linux box running SlimServer has a 1GB/s connection, and
nothing (server or network) is ever loaded very heavily.

> [1] http://www.slimdevices.com/su_faq.html#about2-difference
>
> I've got a wireless SB1, and until recently, I had no problems with
> dropouts caused by network bandwidth (I too play flac files decoded on
> the server and streamed as raw PCM).

I have two SB1s, but both are wired. I wanted to wait until 802.11g was
supported before buying a SB, so I got one of the SB2s with wireless.

But my playback interrupt problems were all over wired paths. I would
have expected problems on 802.11b, but not on an all-wired path with
plenty of capacity.

> I agree with the point you make about threading and making the streaming
> part of slimserver work better, but I don't think the SB or slimserver
> is particularly at fault in causing your dropouts - there must be
> something in your environment that is causing the problem. Maybe the
> port you've got the SB plugged into is not auto-detecting the 10Base-T
> link? Have you checked?

I'm quite sure all my LAN switches are working fine. The playback
interrupt problem is clearly due to sub optimum task scheduling on the
server. If I renice the slimserver and related tasks up a few points,
the playback interruptions disappear, but at the expense of slowing down
everything else on the server whenever the Slimserver wants to do some
sustained maintenance activity like scanning the music filesystem and
rebuilding its database. The Slimserver code should run at high priority
only in its real-time-critical sections, i.e., those directly involved
in playing music. Everything else (e.g., the UI) should run at normal
priority. Database reconstruction could even run at below-normal
priority, just to be nice to the other users.

Another way to minimize playback interruptions is to use lots of read
ahead buffering inside the Slimserver playback path. That covers you in
case the disk is suddenly pre-empted by another urgent I/O-intensive
application. And if you can decompress and buffer up a lot of raw PCM
inside the server, then you're also covered in case a high priority
compute-bound job comes along and pre-empts the FLAC/Ogg Vorbis/AAC/etc
decompresses (which are at least slightly CPU-intensive). If you can
manage to buffer up a lot of raw PCM ready to transmit, then even if the
server is busy running other applications it should be able to spare the
few quick interrupt service calls needed to move that PCM to the
Ethernet transmitter and then to the Squeezebox.

Obviously if the system running Slimserver doesn't have, on average,
enough disk I/O cycles and CPU cycles to supply a full-rate stream to
the Squeezebox, then none of this will help much. But there's no reason
why a fast, lightly loaded machine like mine should have frequent
problems keeping the Squeezebox happy even when the occasional unrelated
load-burst comes along.

Phil