public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
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



  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