Larry,
Firstly, I am sorry you've had trouble getting Softsqueeze to work. Your right some of the information you needed should be in the Softsqueeze FAQ, it is well overdue an update now.
It does sound like something has gone very wrong with Softsqueeze when you run it. As a comparison at work I have one 1.2GHz Athlon with WinXP and Softsqueeze uses between 2% - 5% CPU during playback. In answer to Phil Karn's assumption about being able to call a C based mp3 decoder from Java - well at the moment that's not possible. So Softsqueeze will use more resources than xmms, but it should not be significant on a machine of your spec.
So how to fix this? Can you start Softsqueeze from the command line (instructions for this are on the website), and see if any error messages are reported on the console. If not then email me offlist a thread dump (on the command line press Ctrl + \). This will hopefully give some clues to the problem. Also does the 100% only occur between tracks?
Regards, Richard
[EMAIL PROTECTED] wrote:
Folks,
I'm a big slim devices fan (running an old slimp3 and a wireless squeezebox), and I just tried softsqueeze for the first time. I love the idea, but the performance on my system is barely acceptable. Unless I can figure out how to make it snappier, I may have to go back to XMMS and lose the ability to see the scrolling song information, the cool remote control interface etc. :-(
I'm running a fairly recent two processor (1.4GHz Xeon) linux (Debian) system based on the 2.6 kernel with plenty of memory (>1GB). I'm using the latest jre (1.5.0_01) from sun. I'm using the softsqueeze version (1.12) that it packaged with the current slimserver (5.4.0).
There are several indications of a problems:
* Using "top" to watch CPU usage per process, softsqueeze (actually
java, but softsqueeze is the only java process running)
consistantly takes at least 20% of a CPU, and often nearly 100% of
one. In contrast, playing from the slimserver with XMMS rarely
takes more than 1% of a CPU.
* When the system doing only moderately stressful other tasks, there are often buffer underruns.
* GUI redraws are slow enough to be clearly visible, and occasionally really painfully slow. Painting the preferences dialog seems to take an especially long time (seconds).
I don't doubt this is a java problem rather than a softsqueeze one,
but I don't really speak java. Anyone have any tips about better ways
to profile this, or, better yet, improve it?
Thanks!
Larry Hunter
junk at 180glencoe dot com _______________________________________________
Discuss mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/discuss
_______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
