From: Grant <emailgrant@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Prioritizing mpd
Date: Sat, 13 Jun 2009 06:31:39 -0700 [thread overview]
Message-ID: <49bf44f10906130631j187d0649vb4e479d576a32f18@mail.gmail.com> (raw)
In-Reply-To: <20090613111155.6d042ee9@coercion>
>> 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
next prev parent reply other threads:[~2009-06-13 13:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-12 23:02 [gentoo-user] Prioritizing mpd Grant
2009-06-13 4:30 ` Mike Kazantsev
2009-06-13 4:45 ` Grant
2009-06-13 5:11 ` Mike Kazantsev
2009-06-13 13:31 ` Grant [this message]
2009-06-13 16:32 ` Mike Kazantsev
2009-06-13 8:54 ` Alan McKinnon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49bf44f10906130631j187d0649vb4e479d576a32f18@mail.gmail.com \
--to=emailgrant@gmail.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox