How big is your library? 

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] 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
> _______________________________________________
> Discuss mailing list
> [email protected]
> http://lists.slimdevices.com/lists/listinfo/discuss
> 

_______________________________________________
Discuss mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/discuss

Reply via email to