Comment 17 for bug 37020

A comment from the page I previously referred to:

I want to clarify why this srate=48000 fixes the problem and why its suboptimal in most cases.

Background: Most soundcards can only play one stream at one time. So you normaly wouldn't be able to hear music and hear your instant messenger make "pling" etc. at the same time.
Ubuntu uses alsa with dmix plugin to achieve this functionality. So every application opens a stream to alsa, alsa uses dmix to mix them all together into one stream and sends this to the soundcard.

Ubuntu now is configured so that the dmix plugin opens this audio stream to the soundcard using 48000 Hz. If an application sends an audiostream to alsa which is not 48000 Hz, but e.g. 44100 Hz, then the dmix plugin has to resample this stream into 48000 Hz so it fit's in the sound stream to the card.

Most of our audio material is only 44100 Hz (mp3, video files, kde sounds etc.pp). Only some content is in 48000 Hz natively, e.g. DVD Video.

So every time you have audio not comeing from DVD, dmix plugin has to resample your sound up to 48000 Hz. That costs CPU power for sure! With small files like KDE sounds and instant messenger plings that works fine. For long streams like mp3 or video it seems that the dmix plugin has problems and begins to stutter. If your application resamples to 48000 Hz for itself, then dmix doesn't have to do anything more and it is fine.

But why always resample output when not needed most times? Better solution would be that dmix opens the stream to the soundcard in 44100 Hz and just resamples those few sound streams which use another sample rate. I edited /usr/share/alsa/pcm/dmix.conf and changed the lines
@args.RATE {
type integer
default 48000
}
to
@args.RATE {
type integer
default 44100
}

and I changed mplayer.conf to srate=44100

Now most of the videos work without resampling and no stuttering and only for a few videos mplayer will resample, so dmix has no work with that.