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

Christian Pernegger
2005-03-31, 04:11
>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.

Provided the server and network can provide your audio data at a constant
speed it does just that.

>All it would take is some careful attention paid to proper task/thread
>structuring and prioritization within the Slimserver package.

All transcoding tasks are handled externally in convert.conv. You can modify
the command lines to use "nice" and / or "buffer" to reprioritize and allow
faster-than-realtime transcodes.


2005-04-08, 06:11
How big is your library?

> -----Original Message-----
> From: discuss-bounces (AT) lists (DOT) slimdevices.com
> [mailto:discuss-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of Phil Karn
> Sent: Friday, April 08, 2005 1:03 AM
> To: Slim Devices Discussion
> Subject: Re: [slim] Slim Devices SB2 disappointment & SB for sale.
> 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

2005-04-08, 17:22
My server is a P2/450 running Fedora Core 3. My SB2 is connected via 100Mbps ethernet. I have had zero playback problems with my DTS encoded .wav files. I can't tell you how cool it is to be able to play any DTS track I want, as easily as choosing an MP3.

Server load is 0.60 (I don't worry about playback problems until it rises to 1.5 or higher). And I'm not just playing DTS on my SB2; I'm also simultaneously supporting a second client, a winamp player with on-the-fly re-encoding to 128kbps.