PDA

View Full Version : Hardware Requirements/Guidance



DrJ
2006-04-08, 19:29
I've just become aware of SlimServer, and it looks to be a product that fits exactly a need that I am looking to fill. I've been browsing the fora to determine what sort of horsepower the hardware needs to have to run the server-side software.

Frankly, I'm amazed at the amount of horsepower that some people use. Saturating a 50 or 100Mb Ethernet takes almost nothing (say, a 200MHz PII). As far as I can tell, there is only a php server and maybe a database (or is the filesystem used?) in addition, which shouldn't take that much unless one has a huge collection.

What is a reasonable minimum for a two or three users? FWIW, I was considering running it on an old Sun Ultra 5 with about 256 to 512MB RAM on FreeBSD with enough disk space off an auxilliary controller. Is there any reason this should not work adequately?

DrJ

pfarrell
2006-04-08, 19:40
DrJ wrote:
> Frankly, I'm amazed at the amount of horsepower that some people use.
> Saturating a 50 or 100Mb Ethernet takes almost nothing (say, a 200MHz
> PII).

It is hard to find a computer with as little power as a P2 200.

> As far as I can tell, there is only a php server and maybe a
> database (or is the filesystem used?) in addition, which shouldn't take
> that much unless one has a huge collection.

Its Perl, and there is a lightweight Database.

Part of why people use fairly fast CPUs is that that is what is laying
arround. I used a P3-500 for a long time, it was fine. When it died,
I used a AMD 2200 that I had laying around.


> What is a reasonable minimum for a two or three users? FWIW, I was
> considering running it on an old Sun Ultra 5 with about 256 to 512MB
> RAM on FreeBSD with enough disk space off an auxilliary controller. Is
> there any reason this should not work adequately?

If you have it, try it and see.
Many folks are impatient about things like browser refresh times
and it takes a long time to scan a few hundred gigabytes of songs
because the Perl is not optomized for it, and it happens at night
so most people don't care.

I forget how Sparc memory maps to Intel memory, but my
old P3-500 had under 400 MB of ram.

Transcoding files from weird formats to PCM, Flac or MP3 is
fairly CPU intensive, but if your tunes are in a good format,
then it is just a mindless read block push out NIC until
done loop.


--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

DrJ
2006-04-08, 20:06
It is hard to find a computer with as little power as a P2 200.


That's my point.



Its Perl, and there is a lightweight Database.

My mistake. Still, unless the perl script is terribly involved, this too should not add a lot of overhead. The database should almost be flat, without too much relational "stuff."


If you have it, try it and see.
Many folks are impatient about things like browser refresh times
and it takes a long time to scan a few hundred gigabytes of songs
because the Perl is not optomized for it, and it happens at night
so most people don't care.

I forget how Sparc memory maps to Intel memory, but my
old P3-500 had under 400 MB of ram.

The Ultra 5 (at least the 400MHz variety) is roughly equal to a P3-500. It can map a full 64 bit address space, but for practical purposes, 1GB is about all you can do with an Ultra 5.

If you mean how efficiently memory is used, that's more involved than we can deal with here. Call it the same for present purposes.

Like I said, saturating a 100Mb Ethernet line is not hard. I run much of my admittedly small company off a slower Sparc server, and that includes Samba/print serving, IMAP services, and serving large static web pages by Apache. The server is plenty good enough.


Transcoding files from weird formats to PCM, Flac or MP3 is
fairly CPU intensive, but if your tunes are in a good format,
then it is just a mindless read block push out NIC until
done loop.

That's what was my perception. You can encode once on whatever machine you want, transfer, and then the serving should not take that much.

I may well give it a shot. I figure I can put together this server, with 300GB or so of storage, for about $100.

DrJ



--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html[/QUOTE]

pfarrell
2006-04-08, 20:21
DrJ wrote:
> pfarrell Wrote:
>>Its Perl, and there is a lightweight Database.
>
> My mistake. Still, unless the perl script is terribly involved, this
> too should not add a lot of overhead. The database should almost be
> flat, without too much relational "stuff."

Right not a lot of twelve way joins.


>>I forget how Sparc memory maps to Intel memory, but my
>>old P3-500 had under 400 MB of ram.
>
> The Ultra 5 (at least the 400MHz variety) is roughly equal to a P3-500.
> It can map a full 64 bit address space, but for practical purposes, 1GB
> is about all you can do with an Ultra 5.
>
> If you mean how efficiently memory is used, that's more involved than
> we can deal with here. Call it the same for present purposes.

I was actually thinking that some RISC processors, the Dec Alpha for one
in particular, end up needing a lot more memory to do a given task
than an Intel chip would, in part because the RISC vs CISC theory
and part because the Alpha was 64 bits at a time that lots of PCs were
will using 16 bit addressing.

>>Transcoding files from weird formats to PCM, Flac or MP3 is
>>fairly CPU intensive, but if your tunes are in a good format,
>>then it is just a mindless read block push out NIC until
>>done loop.
>
> That's what was my perception. You can encode once on whatever machine
> you want, transfer, and then the serving should not take that much.

A lot of people are in love with iTunes and Windows weird closed
formats, so their SlimServer has to spend a lot of time
converting (waste a lot of time in some people's minds)

> I may well give it a shot. I figure I can put together this server,
> with 300GB or so of storage, for about $100.

Clearly not with SCSI disks, or do you have them laying around as well?

Clearly try it and see if it runs or walks or is too slow for
your tastes.

--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

rudholm
2006-04-08, 20:54
DrJ wrote:
> pfarrell Wrote:
>>Its Perl, and there is a lightweight Database.
>
> My mistake. Still, unless the perl script is terribly involved, this
> too should not add a lot of overhead. The database should almost be
> flat, without too much relational "stuff."

Right not a lot of twelve way joins.


>>I forget how Sparc memory maps to Intel memory, but my
>>old P3-500 had under 400 MB of ram.
>
> The Ultra 5 (at least the 400MHz variety) is roughly equal to a P3-500.
> It can map a full 64 bit address space, but for practical purposes, 1GB
> is about all you can do with an Ultra 5.
>
> If you mean how efficiently memory is used, that's more involved than
> we can deal with here. Call it the same for present purposes.

I was actually thinking that some RISC processors, the Dec Alpha for one
in particular, end up needing a lot more memory to do a given task
than an Intel chip would, in part because the RISC vs CISC theory
and part because the Alpha was 64 bits at a time that lots of PCs were
will using 16 bit addressing.

>>Transcoding files from weird formats to PCM, Flac or MP3 is
>>fairly CPU intensive, but if your tunes are in a good format,
>>then it is just a mindless read block push out NIC until
>>done loop.
>
> That's what was my perception. You can encode once on whatever machine
> you want, transfer, and then the serving should not take that much.

A lot of people are in love with iTunes and Windows weird closed
formats, so their SlimServer has to spend a lot of time
converting (waste a lot of time in some people's minds)

> I may well give it a shot. I figure I can put together this server,
> with 300GB or so of storage, for about $100.

Clearly not with SCSI disks, or do you have them laying around as well?

Clearly try it and see if it runs or walks or is too slow for
your tastes.

--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

The Ultra 5 uses IDE, so he really could do this on the cheap. And despite how impotent the Ultra 5 is (no disrespect meant, I've been a SPARC user since SPARC-1) it would be enough for running slimserver as long as he didn't do too much simultaneous real-time transcoding.

DrJ
2006-04-08, 21:33
Right not a lot of twelve way joins.

Grin. Understood.


> If you mean how efficiently memory is used, that's more involved than
> we can deal with here. Call it the same for present purposes.

I was actually thinking that some RISC processors, the Dec Alpha for one
in particular, end up needing a lot more memory to do a given task
than an Intel chip would, in part because the RISC vs CISC theory
and part because the Alpha was 64 bits at a time that lots of PCs were
will using 16 bit addressing.

I've not seen that practically on the Sparc, at least not on FreeBSD servers. You do have to pay some attention to the size of various integers and the like, but if you do, there really is not much memory exansion, if any.



> That's what was my perception. You can encode once on whatever machine
> you want, transfer, and then the serving should not take that much.

A lot of people are in love with iTunes and Windows weird closed
formats, so their SlimServer has to spend a lot of time
converting (waste a lot of time in some people's minds)

Well, that brings up another question. I'm obviously suggesting to encode for a high-fidelity storage of the "master" if you will, which would be relayed to the stereo (which is mostly background music for the intended application -- the main audio system is in another carefully acoustically-engineered building) and relying on local processing power (if needed) to do any format conversions when playing on local computers or when transfering to MP3 players.

I've not used iTunes or Windows music formats much. Some sort of front end is useful, particularly for my granddaughter, but as you can probably tell, I've not used any of them much. How fragmented is this part of the world? Are these sorts of format conversions possible (at least those without DRM)? The store-bought CDs I'd think would be OK, but how about music downloads? Can these be converted?


> I figure I can put together this server,
> with 300GB or so of storage, for about $100.

Clearly not with SCSI disks, or do you have them laying around as well?

No, clearly this is not SCSI, and the cost is for buying all the components from scratch. Is SCSI speed for a lightly-loaded server needed? I would think that simple data transfer rate would be more important to stream audio, and for that IDE would be fine (let's leave reliability out of this for the moment). SCSI would put it in a whole 'nother price range, but I did just buy a wonderful Seagate 147GB 10K.6 drive for $80 (four years warranty left). It can be done.

pfarrell
2006-04-08, 21:59
DrJ wrote:
> Well, that brings up another question. I'm obviously suggesting to
> encode for a high-fidelity storage of the "master" if you will, which
> would be relayed to the stereo (which is mostly background music for
> the intended application -- the main audio system is in another
> carefully acoustically-engineered building) and relying on local
> processing power (if needed) to do any format conversions when playing
> on local computers or when transfering to MP3 players.

Some of this realy depends on your usage model.
The SlimDevices SqueezeBox hardware has an embedded microcontroller
that can decode PCM, FLAC and MP3 in the fly, real time.

So if you are streaming to one of them, you are done.

If you are thinking of using a software player,
such as SoftSqueeze, or even WinAmp, then
the driving CPU usage is on the client machine.


> I've not used iTunes or Windows music formats much. Some sort of front
> end is useful, particularly for my granddaughter, but as you can
> probably tell,

I'm not sure I'm following you. Once the tunes are in the server
and the SlimServer is up and running, you use either the remote control
for your SqueezeBox or an HTML window in your favorite browser.
I run Firefox on an ancient Toshiba laptop running Knoppix as
my control, I rarely touch the SqueezeBox remote control.


> I've not used any of them much. How fragmented is this
> part of the world? Are these sorts of format conversions possible (at
> least those without DRM)? The store-bought CDs I'd think would be OK,
> but how about music downloads? Can these be converted?

Store bought CDs have to be 'ripped' into a computer data file
and placed on your server's disk. There are zillions of ripping
utilities.

The Apple iTunes store sells music in a DRM, and Microsoft has its
own DRM. The playing of DRM's music is problematic, as most of
the DRMs are aimed at controlling playback onto a specific
hardware, and your Sun box is not in the top 100 list
of clients.

Most of the 'kids' listen to MP3s, a lot of them may
never have bought a music CD. MP3 files are not too
hard to convert on the fly even using software.

All the cool folks use FLAC, which is free, open source, lossless,
and designed to be low overhead during playback, altho it
is slower than MP3 to compress and doesn't yield as small
file sizes if you are willing to tolerate crappy MP3 rates.

There is a separate mailing list/forum about ripping issues, help
formats, etc.

> No, clearly this is not SCSI, and the cost is for buying all the
> components from scratch. Is SCSI speed for a lightly-loaded server
> needed?

No way. SCSI is not needed at all.
I just mentioned it because all the Sun boxes that I've used
had SCSI. Some other poster said that your Sun box uses
cheap IDE drives. They are more than fast enough.

IDE drives are insanely cheap. $100 will buy new 250GB or larger
disks.

--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

DrJ
2006-04-08, 23:19
And despite how impotent the Ultra 5 is (no disrespect meant, I've been a SPARC user since SPARC-1) it would be enough for running slimserver as long as he didn't do too much simultaneous real-time transcoding.

No offense taken.

That indeed what I was trying to get at with my question. Simple data streaming does not take much horsepower, and while the Ultra 5 will not blind anyone with its speed, it is plenty good enough for filling a simple Ethertube. Still, it is pretty small, consumes little power, can easily be run headless, and is very inexpensive (I bought my last one for $40 loaded). They are also reliable in spite of their being the very low end of Sun's line a long time ago.

Converting formats on-the-fly is not something I had considered. I'll have to look into this more.

DrJ
2006-04-08, 23:54
Some of this realy depends on your usage model.
The SlimDevices SqueezeBox hardware has an embedded microcontroller
that can decode PCM, FLAC and MP3 in the fly, real time.

So if you are streaming to one of them, you are done.

If you are thinking of using a software player,
such as SoftSqueeze, or even WinAmp, then
the driving CPU usage is on the client machine.

The use would be to stream audio to the background audio system, and secondarily to use the same files to feed the house computers for audio and to use them to convert MP3 tracks for players. They have reasonable horsepower. The server would be used to store the master in a format compatible with SqueezeBox, and to use the local machines to do whatever conversion is necessary.


I'm not sure I'm following you. Once the tunes are in the server
and the SlimServer is up and running, you use either the remote control
for your SqueezeBox or an HTML window in your favorite browser.
I run Firefox on an ancient Toshiba laptop running Knoppix as
my control, I rarely touch the SqueezeBox remote control.

Understood. The idea is to store a lossless, high-resolution format on the server, and use that to feed the SqueezeBox or a local computer for playback.


Store bought CDs have to be 'ripped' into a computer data file
and placed on your server's disk. There are zillions of ripping
utilities.

Yes, I know this. But none of the disks I have ever purchased have issues with DRM, so simple format conversions are easy.


The Apple iTunes store sells music in a DRM, and Microsoft has its
own DRM. The playing of DRM's music is problematic, as most of
the DRMs are aimed at controlling playback onto a specific
hardware, and your Sun box is not in the top 100 list
of clients.

Ah. This I didn't know, though on retrospect it does not surprise me. And no, an old Sun on FreeBSD will not make the top of anyone's must-support list.

I'll look at the FAQ, but is it not possible for a computer that downloads the DRM-encoded whatever to convert it to a useable form? If not, then I will have to look into DRM more closely, and the various services for downloading music. If conversion of DRM-encoded music to a form that works for SqueezeBox requires a proprietary OS for the right conversion software, then some thought on my part on what is important is necessary.


Most of the 'kids' listen to MP3s, a lot of them may
never have bought a music CD. MP3 files are not too
hard to convert on the fly even using software.

And they are absolute junk as far as audio quality goes.


IDE drives are insanely cheap. $100 will buy new 250GB or larger
disks.

Sure. You can easily get a new 160GB drive for $20 or $30 if you are careful.

JJZolx
2006-04-09, 00:05
That indeed what I was trying to get at with my question. Simple data streaming does not take much horsepower, and while the Ultra 5 will not blind anyone with its speed, it is plenty good enough for filling a simple Ethertube. Still, it is pretty small, consumes little power, can easily be run headless, and is very inexpensive (I bought my last one for $40 loaded). They are also reliable in spite of their being the very low end of Sun's line a long time ago.

Converting formats on-the-fly is not something I had considered. I'll have to look into this more.
The speed differences between lesser hardware and something beefier are mostly noticed in user interface responsiveness and library scanning times. I find the latter to be fairly unimportant, within reason. I'm not up for waiting 10 hours to scan my library as some NAS users put up with, but the difference between 15 and 30 minutes isn't worth worrying about.

It's the user interface, particularly the web interface that I use almost exclusively, where I can't tolerate long waits. The web UI of SlimServer is becoming more and more of a (read only) music library manager at the behest of users, with better search capability, some handy plugins, and an increasingly nice, but complex web interface. Some people on marginal hardware see occasional performance problems that affect the audio (causing drop outs) when they're streaming while using the web interface. Streaming and simultaneously scanning is impossible on many platforms.

Version 6.5 will be utilizing MySQL with InnoDB tables for its database back end. No twelve-way joins, but once the dbms has been upgraded to MySQL I expect that a lot of queued up enhancement requests for the web interface will be forthcoming. These will require more and more complex database interaction; certainly four and five way joins aren't out of the question. I imagine Slim Server developers will have to walk a fairly thin line between features and complexity, since most users will not have dedicated servers and the application needs to run on everyday desktops and laptops being used for other tasks.

tom permutt
2006-04-09, 05:42
I've not used iTunes or Windows music formats much. Some sort of front end is useful, particularly for my granddaughter, but as you can probably tell, I've not used any of them much. How fragmented is this part of the world? Are these sorts of format conversions possible (at least those without DRM)? The store-bought CDs I'd think would be OK, but how about music downloads? Can these be converted?Yes, there is software to convert between formats and also play them on the PC. dBPowerAmp is one option. It will play files in the "cool kids" flac format and also convert most anything to most anything else you might want. There is a small charge for the MP3 encoder, if you want that, because the author is one of about three people on the planet actually to pay the patent royalty.

DrJ
2006-04-09, 09:28
The speed differences between lesser hardware and something beefier are mostly noticed in user interface responsiveness and library scanning times. ...
It's the user interface, particularly the web interface that I use almost exclusively, where I can't tolerate long waits. The web UI of SlimServer is becoming more and more of a (read only) music library manager at the behest of users, with better search capability, some handy plugins, and an increasingly nice, but complex web interface. Some people on marginal hardware see occasional performance problems that affect the audio (causing drop outs) when they're streaming while using the web interface. ...

Version 6.5 will be utilizing MySQL with InnoDB tables for its database back end. ... These will require more and more complex database interaction; certainly four and five way joins aren't out of the question. I imagine Slim Server developers will have to walk a fairly thin line between features and complexity, since most users will not have dedicated servers and the application needs to run on everyday desktops and laptops being used for other tasks.

That's all very helpful -- thank you.

It would be my assumption that using the remote with SlimServer does not take a lot of overhead. It is the searching from a computer that does. It that right?

It makes sense to use MySQL (or Postgres) for the library cataloging functions, particularly with the emphasis on FOSS software. And yes, I can see how searching, say, for tracks from all artists who recorded on Verve in 1957 that use a quartet including a piano would take quite some hardware to be quick. The disk subsystem in particular would be thrashed.

What is prompting this examination is that I'm looking to spec out a home server. We are just getting too much information (music, video clips, pictures and documents) scattered on different machines that it is getting cumbersome both to access it and to back it up. Some of the laptops are running out of disk space. So I'm looking to centralize a lot of that, and probably will also include a print server just to make it neat.

My wife mentioned that she would like to include the house stereo on it, and that's what lead me here.

I'm by no means arguing for a low-end machine, though the Ultra 5 is a favorite of mine for such simple tasks. It may be better to get a faster machine (or a dual processor, since MySQL uses threads effectively), but practically I doubt there will be much simultaneous access for music through the web interface. There may be file serving while music is playing, though, so I'll have to consider how heavy that load would be.

I may just have to try it. It would be easy enough to set up a test bed and see how heavy the web interface is on system resources while something else is playing.

DrJ
2006-04-09, 09:33
Yes, there is software to convert between formats and also play them on the PC. dBPowerAmp is one option. It will play files in the "cool kids" flac format and also convert most anything to most anything else you might want. There is a small charge for the MP3 encoder, if you want that, because the author is one of about three people on the planet actually to pay the patent royalty.

That too is helpful -- thanks.

I've seen two comments now on the "cool kids" FLAC format. Any reason for the modifier? Sometimes the "cool kids" are right, sometimes they are lead more by religious issues (such as Micro$oft is evil). What the deal?

Siduhe
2006-04-09, 09:45
Highbitrate mp3 will still sound pretty good on your average low-end hifi, so unless you have a good to high-end system, you may not need to use FLAC for "audiophile" reasons.

However, FLAC is a) lossless and b) opensource. Whether that makes it a sensible choice for anyone who doesn't want to create a bunch of lossy files and then have to rerip them all when the next musical innovation comes out or b) just for "cool kids" is a matter of personal choice.

You can't use FLAC on most portable music players (and things like WMP need plugins), but as it's lossless, it's easy to convert them to a seperate library (see the great script that someone here wrote called "flac to mp3").

There's an increasing number of rippers that will rip to FLAC in one interface - EAC, DBPowerAmp and Audiograbber for three (check out the wiki)

HTH

DrJ
2006-04-09, 10:25
FLAC is a) lossless and b) opensource. ... You can't use FLAC on most portable music players (and things like WMP need plugins), but as it's lossless, it's easy to convert them to a seperate library (see the great script that someone here wrote called "flac to mp3").
HTH

Lossless and Open Source are both good, as long as the format catches on. Some do and some don't. It does seem like a good choice for storing a "master" format as is my interest.

Am I understanding you correctly that things like WMP or RealPlayer can do a client-side format conversion through a plug-in that is transparent to the user? That is, the server would send the file in FLAC format, and the client computer does the conversion on the fly, as opposed to having the server do it.

rudholm
2006-04-09, 16:50
Lossless and Open Source are both good, as long as the format catches on. Some do and some don't. It does seem like a good choice for storing a "master" format as is my interest.

Am I understanding you correctly that things like WMP or RealPlayer can do a client-side format conversion through a plug-in that is transparent to the user? That is, the server would send the file in FLAC format, and the client computer does the conversion on the fly, as opposed to having the server do it.

Yes, there are FLAC plugins for most popular players; XMMS, WinAMP, WMP...

Lossless makes a lot of sense since it obviates the original CD (never re-rip again) and, as you point out, disk space is exceedingly inexpensive. I get about 3 CDs per GB with FLAC, which is what, about a dime per CD in disk space? FLAC is a good choice because it's probably the most widely accepted free lossless format, it's easy to decode (integer math) so it is supported by a reasonable amount of hardware (Squeezebox, Sonos, various portable players, etc). You can even play FLAC on an iPod if you use the Rockbox firmware. See http://flac.sourceforge.net/ for more of the brochure :)

tom permutt
2006-04-09, 17:01
I've seen two comments now on the "cool kids" FLAC format. Any reason for the modifier? Sometimes the "cool kids" are right, sometimes they are lead more by religious issues (such as Micro$oft is evil). What the deal?I didn't mean to imply anything negative. I use flac. I'm not religious. It's lossless but tagged, it works well with the SqueezeBox, and I can use flac2mp3 to maintain a parallel tree of lossy files for a portable player.

DrJ
2006-04-09, 18:47
Yes, there are FLAC plugins for most popular players; XMMS, WinAMP, WMP...

That's good to know -- thanks!


I get about 3 CDs per GB with FLAC, which is what, about a dime per CD in disk space?

That's pretty good compression, actually. IIRC, Sony settled on 500GB per CD so that all of Beethoven's 9th Symphony could fit on one CD at the then-present sampling rates. For a lossless compression, a one-third reduction is not bad at all.

It would seem that the only downsides are file size (not important) and network traffic, which becomes less of an issue if you use a wired connection (higher rate and less overhead).

DrJ
2006-04-09, 18:56
I didn't mean to imply anything negative. I use flac. I'm not religious. It's lossless but tagged, it works well with the SqueezeBox, and I can use flac2mp3 to maintain a parallel tree of lossy files for a portable player.

Understood. It was just that the phrase "cool kids" was so prominent and, well, unusual, that I did not know what to make of it. It could have been akin to a Linux newbie asking about the best Linux distro and someone replying "Linux from Scratch." That would be the "cool" way to do it, but also totally unworkable for said newbie.

I was also reminded of the old IBM commercial where the young pup is trying to sell the crusty old CEO on some new technology, claiming that is was "cool." Crusty's response? "Cool? Cool costs me money." Since this was a commercial, crusty came around, but his response mirrors my experience to some extent.

So thanks for following up and clarifying.

rudholm
2006-04-09, 19:29
That's good to know -- thanks!

That's pretty good compression, actually. IIRC, Sony settled on 500GB per CD so that all of Beethoven's 9th Symphony could fit on one CD at the then-present sampling rates. For a lossless compression, a one-third reduction is not bad at all.

It would seem that the only downsides are file size (not important) and network traffic, which becomes less of an issue if you use a wired connection (higher rate and less overhead).

Well, a Red Book compliant CD is 74 minutes, but some CDs out there are even longer. Some of them will even play on a compliant player ;-) And most discs don't use 100% of capacity anyway. Red discs read 75 2352-byte sectors per second, which actually turns out to be nearly 800MB per disc maximum. (this is more than a standard Yellow Disc because Red Discs have less forward error correction).

Data-wise, I see a bit less than 2:1 compression on most music with FLAC. Classical and ambient material compresses more. My "three CDs per gig" rule of thumb is based on my personal CD collection, but I find that other people's experience is generally in this area.

The then-present sampling rate for CDs was the same as it is now: 44,100 16-bit samples per second per channel. This is the Red Book standard. New formats (e.g. SACD and DVD-Audio) change both the quantization resolution as well as the sample rate, but those won't play on a CD-DA player, and I don't believe the Squeezebox supports those standards (yet).

Pale Blue Ego
2006-04-09, 21:49
Bottom line, the Sun Ultra 5 should be plenty of horsepower to host and serve a sizeable collection.

It costs nothing to download the perl source and run it - on Linux, I just start the slimserver.pl from the command line and let it run in its own console. Point any browser on the network to http://host:9000 to configure it. You can run the Softsqueeze emulator on any Java-enabled platform on the network to test the server's playback performance. If it is satisfactory, order a real Squeezebox (or two!). Done.