Tuning
From Music Player Daemon Community Wiki
This page is a collection of tuning tips.
Contents |
[edit] Samplerate converting - or why does ALSA consume much more CPU than OSS?
Most on-board sound chips only support 48 kHz, while most music is 44.1 kHz. That means, MPD has to convert the sample rate, using libsamplerate by default. libsamplerate consumes a lot of CPU cycles, somewhere around 5-20%. You can disable libsamplerate at compile time with the flag "--disable-lsr", then MPD will fall back to a very simple algorithm with poor quality. Its CPU usage should decline to below 1% now (only if you disable dmix, see below).
Now why does OSS consume a lot less CPU (even with OSS-ALSA emulation)? Well, ALSA's OSS emulation produces nearly the same poor quality as MPD's fallback algorithm. In the end, it's a quality versus performance trade-off: either you have good quality and high CPU usage, or you have poor quality but low CPU usage. You have the choice.
[edit] Choosing the resampling algorithm
If an audio output device doesn't support a specific sample rate, MPD performs resampling. Most of the time, it is favorable to use MPD's resampling with libsamplerate.
OSS-ALSA has built-in resampling which cannot be disabled. With plain ALSA (mpd-mk only), you can disable resampling with the "auto_resample" option:
audio_output {
type "alsa"
name "my ALSA device"
auto_resample "no"
}
The manual page provides more information about that, and how to choose libsamplerate's algorithm.
Note: if you don't have libsamplerate installed, and you still have higher CPU consuming, than expected, check if there's libasound_module_rate_speexrate.so installed. Probably it's the reason.
[edit] ALSA with mmap
Enabling mmap optimizes CPU usage a little, and is possible on most sound hardware:
audio_output {
type "alsa"
name "my ALSA device"
use_mmap "yes"
}
[edit] ALSA dmix
Since version 1.0.9-rc2, ALSA enables dmix (allows multiple applications to play audio on a single sound card) by default. dmix is a little overhead, if you want direct output to the device, use something like the following syntax:
audio_output {
type "alsa"
name "my ALSA device"
device "hw:0,0"
}
Another reason to bypass dmix is that dmix forces 48khz (see here). So if you playback 44.1khz this will require resampling even if your soundcards supports 44.1khz samplerate, this causes extra cpu usage.
[edit] Force ALSA dmix to 44.1khz
Taken from http://alsa.opensrc.org/Dmix : Does dmix affect sound quality?.
Dmix resamples everything to 48khz. (see above url). You can force dmix to resample at 44.1khz, by setting (in /etc/asound.conf or ~/.asoundrc):
pcm.!default {
type plug
slave.pcm {
type dmix
ipc_key 1024
slave {
pcm "hw:0,0"
rate 44100
}
}
}
Also, you should keep in mind, that software mixing is possible only, if all signals are at the same sample rate. So, if you want to play DVD's, which use 48kHz sample rate for audio, with this kind of plug, everything will be downsampled to 44.1kHz. Unfortunatelly it does'nt work very well (there are some syncronization problems with some players). In this case you have two opportunities, either use a separate plug (and loose ability to playback mp3 and dvd on the same time) or tell your DVD player to sample audio down to 44.1khz.
[edit] Checking actual sample rate
Say you want to check what sample rate is actually running playing audio? With alsa you can get this from your proc. F.e. on your first soundcard:
cat /proc/asound/card0/pcm0p/sub0/hw_params
This reports the rate (sample rate), bit depth, format etc.
example output (edirol UA1EX soundcard, fixed at 16bit, 44.1khz):
access: RW_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 44100 (44100/1) period_size: 45 buffer_size: 22050
The exact path can be different, f.e. if your cards has multiple outputs you can also have a pcm1p.
note: the pcm0c is the capture device.
[edit] Profiling
See Oprofile
