Tuning

This page is a collection of tuning tips.

Samplerate converting - or why does ALSA consume much more CPU than OSS does?

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.

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. Taking a look for samplerate_converter in your mpd.conf is good start point, consult manual of mpd.conf for possible values. Setting:

samplerate_converter            "internal"

should result in immediate CPU usage drop. For the cost of quality, of course, but output still can be satisfactionary, especially for Internet radios. After this you will know, if resampling is really the source of CPU usage.

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.

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"
}

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.

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 DVDs, which use 48kHz sample rate for audio with this kind of plug, everything will be downsampled to 44.1kHz. Unfortunately, it doesn't work very well (there are some syncronization problems with some players). In this case you have two options: either use a separate plug (and lose the ability to playback mp3 and dvd at the same time) or tell your DVD player to sample audio down to 44.1khz.

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.

Profiling

See Oprofile