Music Machine said the following on 11/10/2005 23:13:
Two cents from the Peanut Gallery
It seems like people are pretty happy with performance if they have
around 350 or less albums in the database. 750 albums or more is about
the place where no one seems satisfied with performance. Between those
quantities satisfaction varies quite a bit. I could easily have missed
posts to the contrary.
My slimserver installation is currently reporting:
1273 albums with 12943 songs by 529 artists
I run Fedora Core 4 Linux on a (dual) P3 1GHz processor with 1.5GB RAM.
This box is also my mail server, web server, database server, samba
server, etc. I also use a MySQL backend and always run the latest dev.
code from svn trunk.
Normal operation is fine. In fact, I've never had any *real* problems
with slimserver.
However, the current architecture is such that any blocking operation
will interrupt audio streaming if it blocks for long enough.
As Model Citizen rightly says, I have been advocating breaking the code
up into separate processes or threads for sometime. I have also
discussed this at some length with Dan.
Unfortunately, I'm not in a position to contribute much time/effort to
developing code at the moment and the Slim team are even more busy so
the initiative is on the back-burner.
On the surface it looks like data handling is the bottleneck, not
processing power.
It's more about spreading the processing power between the necessary
processes. The core "real-time" processes need to run uninterrupted,
e.g. audio streaming, display update, response to remote, etc. Other
stuff, like playlist management, scanning, etc. need as much CPU as
possible but without interrupting the core processes. This would be
easier to achieve with a multi-process/thread architecture.
R.
--
http://robinbowes.com
If a man speaks in a forest,
and his wife's not there,
is he still wrong?
_______________________________________________
Discuss mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/discuss
