On Wed, 03 Mar 2004 22:57:05 +0800 Zhang Weiwu <[EMAIL PROTECTED]> probably wrote:
> Things can hardly be perfect. Now I begin to use mpg123, I used your
> method of "rtprio up and su back", very useful to me.
>
> But if mpg123 has higher priority than ppp, sometimes mpg123 decides to
> move to another song, it reloads buffer, starveing ppp and timeouting
> bluetooth device... If mpg123 has equal/lower priority with ppp, they
> struggle for CPU, and that *sounds* bad. Now I adjusted buffer, it works
> so so.
>
> I read the handbook it says "no way to limit CPU percentage". It's my
> toy, a old P166M box, I let other people in the office ssh to the box
> with cmp3 console DJ (backended mpg123) to play music, because it has
> good speakers. I use ppp over bluetooth to connect to the box when I'm
> enjoying sun shine outdoor.
You still didn't post the whole of top(1) output.
FWIW splay has a -2 switch that permits it to generate half that
quality output using half that processor cycles (not sure about
mpg123). Unless the people out there are melomaniacs, that may be
sufficient.
P.S. It *seems* possible to use a little hack to renice the mp3 player
after it has loaded the new song. That is, every time a new song is
being played, launch both the player and a separate shell process
which sleep(1)s for a second, and then rtprio's the player. For one
song, it will *probably* look like this:
---------begin playsong.sh--------
#!/bin/sh
mpg123 $1&
MPG123_PID=$!
(sleep 1; sudo rtprio 3 -${MPG123_PID})&
wait
---------end playsong.sh--------
assuming you have the appropriate line in your sudoers file (the '-'
before the ${MPG123_PID} is not a typo).
--
DoubleF
"I refuse to have a battle of wits with an unarmed person."
pgp00000.pgp
Description: PGP signature
