[gentoo-user] Prioritizing mpd

[gentoo-user] Prioritizing mpd

[Grant]

When I use the medium quality libsamplerate resampler with mpd, my CPU
is around 15% and all is well.  When I try to use the best quality
resampler, the CPU stays around 99% and the sound frequently falls
apart.  Can I give mpd CPU priority?

- Grant

Re: [gentoo-user] Prioritizing mpd

[Mike Kazantsev]

[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

On Fri, 12 Jun 2009 16:02:00 -0700
Grant <emailgrant@gmail.com> wrote:

> When I use the medium quality libsamplerate resampler with mpd, my CPU
> is around 15% and all is well.  When I try to use the best quality
> resampler, the CPU stays around 99% and the sound frequently falls
> apart.  Can I give mpd CPU priority?

Yes, it's usually done via nice/renice commands:
  
  renice -n -10 -p `pgrep mpd`

You can tune it's priority up to -20 (most real-time priority).

I'd suggest looking at load-average it generates ("top" shows it, at the
top)) first.
After running mpd for 15 minutes or so, if any of the three (5/10/15)
will go above number of physical CPU cores you have (and that's
probably the case if you see full load at any given time), tuning it's
priority up will make the rest of the system extremely sluggish, since
mpd won't let any other process to execute and just doing "ls" may take
ages, not to mention whole X operation...

-- 
Mike Kazantsev // fraggod.net

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Prioritizing mpd

[Grant]

>> When I use the medium quality libsamplerate resampler with mpd, my CPU
>> is around 15% and all is well.  When I try to use the best quality
>> resampler, the CPU stays around 99% and the sound frequently falls
>> apart.  Can I give mpd CPU priority?
>
> Yes, it's usually done via nice/renice commands:
>
>  renice -n -10 -p `pgrep mpd`
>
> You can tune it's priority up to -20 (most real-time priority).
>
> I'd suggest looking at load-average it generates ("top" shows it, at the
> top)) first.
> After running mpd for 15 minutes or so, if any of the three (5/10/15)
> will go above number of physical CPU cores you have (and that's
> probably the case if you see full load at any given time), tuning it's
> priority up will make the rest of the system extremely sluggish, since
> mpd won't let any other process to execute and just doing "ls" may take
> ages, not to mention whole X operation...

Thanks Mike.  I tried:

renice -20 -p `pgrep mpd`

but my Athlon 2.2Ghz still can't handle it for more than a few
seconds.  I don't have SMP enabled because of a bug in madwifi, and
I'm hoping when I get that fixed I'll be able to run the best
libsamplerate resampler.  Any other ideas for making this work?

- Grant

Re: [gentoo-user] Prioritizing mpd

[Mike Kazantsev]

[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]

On Fri, 12 Jun 2009 21:45:02 -0700
Grant <emailgrant@gmail.com> wrote:

> renice -20 -p `pgrep mpd`
> 
> but my Athlon 2.2Ghz still can't handle it for more than a few
> seconds.  I don't have SMP enabled because of a bug in madwifi, and
> I'm hoping when I get that fixed I'll be able to run the best
> libsamplerate resampler.  Any other ideas for making this work?

AFAIK resampling is expensive operation that's only necessary when your
sound card can't handle native stream sample rate, furthermore, it's a
lossy operation (degrading quality).

So, I'd look for the answer to the question "why mpd is doing it and
why I allow it to do that?".
For example, you might have enabled it to resample stream to 32 bits
depth, while your built-in card can only handle 16 and the stream has
also 16, so what happens is userspace-level conversion (with some loss
of quality) to 32, loading your CPU, then this stream goes to alsa,
and, provided that your card can't play this, driver or the card itself
converts it back to 16.
Note that the latter case would probably mean "card offloads conversion
to your CPU as well", so you'll get CPU load for both ways' conversion
anyway, only reducing sound quality, no matter how good converters are.

To avoid any processing, try disabling resampling in mpd, since it'll
probably be done for you anyway, if necessary (you'll hear "white
noise" otherwise).

And you can pre-convert all the streams to any given samplerate, but
note that you'll probably get far worse results if the target format
isn't lossless (flac, ape), even if the source one is lossy, than with
worst resampling.
And you can get worse CPU/IO load with lossless format in the end,
since it's harder to decode and the input data stream is much heavier
than with lossy mp3s or oggs.

-- 
Mike Kazantsev // fraggod.net

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Prioritizing mpd

[Alan McKinnon]

On Saturday 13 June 2009 06:30:56 Mike Kazantsev wrote:
> On Fri, 12 Jun 2009 16:02:00 -0700
>
> Grant <emailgrant@gmail.com> wrote:
> > When I use the medium quality libsamplerate resampler with mpd, my CPU
> > is around 15% and all is well.  When I try to use the best quality
> > resampler, the CPU stays around 99% and the sound frequently falls
> > apart.  Can I give mpd CPU priority?
>
> Yes, it's usually done via nice/renice commands:
>
>   renice -n -10 -p `pgrep mpd`
>
> You can tune it's priority up to -20 (most real-time priority).

Don't be surprised if it doesn't do much though.

Nice values have always been little more than a hint in Unix systems, the 
kernel is free to do with it whatever it wants, including completely ignoring 
your hint.

To a large degree, Linux does exactly that - ignore the hint. It does have an 
effect, a small one, and usually much smaller than the user expects. Nice is 
an old, antiquated, obsolete and just plain mostly useless way to enforce 
scheduling, entirely unsuited to modern desktops. The better way is to select 
a scheduling algorithm that better suits your needs and let the kernel figure 
out how to give you what you want (it knows MUCH more about how to do it than 
you do).

Or perhaps the OP is using a buggy peice of code. CPU utilization is also a 
notoriously inaccurate metric that does not mean what people tend to think it 
means.

This information is not in the man pages. 
It's on lkml and in the code ;-)

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Prioritizing mpd

[Grant]

>> renice -20 -p `pgrep mpd`
>>
>> but my Athlon 2.2Ghz still can't handle it for more than a few
>> seconds.  I don't have SMP enabled because of a bug in madwifi, and
>> I'm hoping when I get that fixed I'll be able to run the best
>> libsamplerate resampler.  Any other ideas for making this work?
>
> AFAIK resampling is expensive operation that's only necessary when your
> sound card can't handle native stream sample rate, furthermore, it's a
> lossy operation (degrading quality).
>
> So, I'd look for the answer to the question "why mpd is doing it and
> why I allow it to do that?".
> For example, you might have enabled it to resample stream to 32 bits
> depth, while your built-in card can only handle 16 and the stream has
> also 16, so what happens is userspace-level conversion (with some loss
> of quality) to 32, loading your CPU, then this stream goes to alsa,
> and, provided that your card can't play this, driver or the card itself
> converts it back to 16.
> Note that the latter case would probably mean "card offloads conversion
> to your CPU as well", so you'll get CPU load for both ways' conversion
> anyway, only reducing sound quality, no matter how good converters are.
>
> To avoid any processing, try disabling resampling in mpd, since it'll
> probably be done for you anyway, if necessary (you'll hear "white
> noise" otherwise).
>
> And you can pre-convert all the streams to any given samplerate, but
> note that you'll probably get far worse results if the target format
> isn't lossless (flac, ape), even if the source one is lossy, than with
> worst resampling.
> And you can get worse CPU/IO load with lossless format in the end,
> since it's harder to decode and the input data stream is much heavier
> than with lossy mp3s or oggs.
>
> --
> Mike Kazantsev // fraggod.net

I'm upsampling my 16/44.1 files to 24/96 because it sounds much better
than letting the USB DAC do it.  This was actually recommended by the
manufacturer and it sounds much better.

Pre-converting sounds interesting.  I could convert all of my 16/44.1
files to 24/96 files?  That way the CPU wouldn't be stressed at
playback time.  How can I do that?  I use libsamplerate "Best" for
resampling.

- Grant

Re: [gentoo-user] Prioritizing mpd

[Mike Kazantsev]

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

On Sat, 13 Jun 2009 06:31:39 -0700
Grant <emailgrant@gmail.com> wrote:

> Pre-converting sounds interesting.  I could convert all of my 16/44.1
> files to 24/96 files?  That way the CPU wouldn't be stressed at
> playback time.  How can I do that?  I use libsamplerate "Best" for
> resampling.

Just use flac/lame/vorbis-tools, they have all the capabilities you
need.

  lame --decode /some/file.mp3 - | \
    flac --bps=24 --sample-rate=96 - file.flac

  lame --decode /some/file.mp3 - | \
    oggenc --resample 24000 -q 6 - -o file.ogg

  lame --resample 24 --preset standard /some/file.mp3 file.mp3

Try tweaking quality settings / listening to results in different
formats to pick the best one for you.
ogg and mp3 should result in some loss of sound quality, although it
might be insignificant while compression benefit over flac is quite
noticeable.

-- 
Mike Kazantsev // fraggod.net

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]