1 |
On Saturday 13 June 2009 06:30:56 Mike Kazantsev wrote: |
2 |
> On Fri, 12 Jun 2009 16:02:00 -0700 |
3 |
> |
4 |
> Grant <emailgrant@×××××.com> wrote: |
5 |
> > When I use the medium quality libsamplerate resampler with mpd, my CPU |
6 |
> > is around 15% and all is well. When I try to use the best quality |
7 |
> > resampler, the CPU stays around 99% and the sound frequently falls |
8 |
> > apart. Can I give mpd CPU priority? |
9 |
> |
10 |
> Yes, it's usually done via nice/renice commands: |
11 |
> |
12 |
> renice -n -10 -p `pgrep mpd` |
13 |
> |
14 |
> You can tune it's priority up to -20 (most real-time priority). |
15 |
|
16 |
Don't be surprised if it doesn't do much though. |
17 |
|
18 |
Nice values have always been little more than a hint in Unix systems, the |
19 |
kernel is free to do with it whatever it wants, including completely ignoring |
20 |
your hint. |
21 |
|
22 |
To a large degree, Linux does exactly that - ignore the hint. It does have an |
23 |
effect, a small one, and usually much smaller than the user expects. Nice is |
24 |
an old, antiquated, obsolete and just plain mostly useless way to enforce |
25 |
scheduling, entirely unsuited to modern desktops. The better way is to select |
26 |
a scheduling algorithm that better suits your needs and let the kernel figure |
27 |
out how to give you what you want (it knows MUCH more about how to do it than |
28 |
you do). |
29 |
|
30 |
Or perhaps the OP is using a buggy peice of code. CPU utilization is also a |
31 |
notoriously inaccurate metric that does not mean what people tend to think it |
32 |
means. |
33 |
|
34 |
This information is not in the man pages. |
35 |
It's on lkml and in the code ;-) |
36 |
|
37 |
-- |
38 |
alan dot mckinnon at gmail dot com |