Mplayer sound playback is choppy when using ALSA plugin

[Vytas]

Sound playback is choppy when using ALSA plugin. ESD, OSS and other work fine.

I am using latest mplayer from Dapper repositories.

[Reinhard Tartler (siretart)]

Thanks for taking the time to report this bug. Unfortunately, we are not able to fix and find the bug because your description of the bug didn't have enough information in it. You may find it helpful to read "How to report bugs effectively", http://www.chiark.greenend.org.uk/~sgtatham/bugs.html (''this link seems broken''). We'd be grateful if you would then provide a more complete description of the problem.

Debugging procedures for certain types of problems can be found at http://wiki.ubuntu.com/DebuggingProcedures

On my machines, using the alsa plugin works just fine. Do you have a speculation why it doesn't work too well for you?

[Vytas (vytas)]

Reinhard, no, I dont have any ideas why it is not working as expected. Alsa sound system seems to be ok, gstreamer based programs work fine.

My audio hardware:
~$ cat /proc/asound/cards
0 [Intel ]: HDA-Intel - HDA Intel
                     HDA Intel at 0xffa3c000 irq 169

Maybe this output of mplayer/alsa might be helpful...
____________________________________________________
Building audio filter chain for 44100Hz/2ch/s16le -> 0Hz/0ch/??...
alsa-init: 1 soundcard found, using: default
alsa: 44100 Hz/2 channels/4 bpf/60208 bytes buffer/Signed 16 bit Little Endian
AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample)
Building audio filter chain for 44100Hz/2ch/s16le -> 44100Hz/2ch/s16le...
Starting playback...
alsa-space: xrun of at least 0.680 msecs. resetting stream?,?% 0 0
alsa-space: xrun of at least 0.677 msecs. resetting stream?,?% 1 0
alsa-space: xrun of at least 0.674 msecs. resetting stream0.1% 2 0
alsa-space: xrun of at least 0.702 msecs. resetting stream0.1% 3 0
alsa-space: xrun of at least 0.679 msecs. resetting stream0.1% 4 0
alsa-space: xrun of at least 1.287 msecs. resetting stream0.2% 5 0
alsa-space: xrun of at least 0.707 msecs. resetting stream0.2% 6 0
alsa-space: xrun of at least 1.816 msecs. resetting stream0.3% 8 0

__________________________
The problem arises even when playing Vorbis files, so it is most probably codec unrelated. Also, using ESD all formats play as expected.

The problem arises when using various interfaces, like gmplayer, mplayer from the command line.

If there is something specific that you would like to know, I could try to provide the missing information.

[Vytas (vytas)]

Also, I had a thought that mplayer-686 might be having specific issues, but mplayer-386 gives the same results.

[Sebastian Dröge (slomo)]

Am Dienstag, den 28.03.2006, 16:56 +0000 schrieb Vytas:
> Public bug report changed:
> https://launchpad.net/malone/bugs/37020
>
> Comment:
> Also, I had a thought that mplayer-686 might be having specific issues,
> but mplayer-386 gives the same results.

There currently is only the mplayer, mplayer-nogui and mencoder package.
The mplayer-* packages are only transitional ones that are needed as we
had different packages for different architectures before

[Vytas (vytas)]

Thanks for the clarification.

[Yagisan (yagisan)]

You may benefit from this, it allows mplayer to have finer timing. It is not on my default because it generates a high interupt load, which is not suitable for multiuser machines.

sudo gedit /etc/sysctl.conf

add the following line:
dev.rtc.max-user-freq=1024

save, reboot, and report back your results.

[Vytas (vytas)]

It seems that max-user-freq has nothing to do with this; no effect.

[Yagisan (yagisan)]

You may benefit from this, it allows mplayer to have finer timing. It is not on my default because it generates a high interupt load, which is not suitable for multiuser machines.

sudo gedit /etc/sysctl.conf

add the following line:
dev.rtc.max-user-freq=1024

save, reboot, and report back your results.

[Yagisan (yagisan)]

Ignore last post. firefox troubles :( anyway, I'm out ideas for the moment - It looked like there are delays in your alsa outout so I thought high-res timing may help.

[Vytas (vytas)]

Well, it seems ALSA unrelated, because as I've said gstreamer programs work well with ALSA output, so does VLC.

I mostly use these two (totem (gst) & VLC) so this is not a serious issue for me, however mplayer is very popular among users, too.

[Reinhard Tartler (siretart)]

surely it is, but we need to know why this issue occurs on YOUR particular machine but not on others machines.

[Vytas (vytas)]

If there is any useful information I can provide I will try to help.

[Vytas (vytas)]

Maybe this might cause problems?
____________________________________

$ mplayer *mpg
MPlayer 2:0.99+1.0pre7try2+cvs20060117-0ubuntu6 (C) 2000-2006 MPlayer Team
CPU: Intel Pentium 4/Celeron D Prescott; Xeon Nocona (Family: 15, Stepping: 4)
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled with runtime CPU detection.

91 audio & 204 video codecs
Failed to open /dev/rtc: No such file or directory (it should be readable by the user.)
Opening joystick device /dev/input/js0
Can't open joystick device /dev/input/js0: No such file or directory
Can't init input joystick
Setting up LIRC support...
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support.
You will not be able to use your remote control.

[Gary Coady (garycoady)]

I also get this problem on my laptop. The audio is an Intel HDA controller, part of the 915GM chipset:
82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller

With the default alsa settings, both video and audio are interrupted around once per second with the kind of error reported earlier.

Workarounds I've found include:
1. adding "srate=48000" to /etc/mplayer/mplayer.conf
2. adding "-ao alsa:mmap" when running mplayer
3. adding "-ao oss" when running mplayer

If you search google for the error, this page appears:
https://bugtrack.alsa-project.org/wiki/wikka.php?wakka=HighDefinitionAudio
All reports of this problem include mentions of this type of hardware.

[Daniel T Chen (crimsun)]

Unfortunately there's no conditional application of parameters in /etc/mplayer/mplayer.conf (i.e., "only 'apply srate=48000' if /proc/asound/modules contains 'snd_hda_intel'"). Furthermore, said parameter(s) will break many audio configurations that don't accept 48000 per default (e.g., my M-Audio Transit USB).

[Munzir Taha (منذر طه) (munzirtaha)]

I also met across it today. Shouldn't this be changed from "Needs Info" to someting more relavent now after Gary explanation?

[Gary Coady (garycoady)]

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.

[William Grant (wgrant)]

It works fine with ICH6 again since Edgy, on the same hardware which had issues in Dapper.