Opened 11 years ago

Last modified 6 years ago

#1408 reopened defect

pulseaudio and mplayer sticky pause

Reported by: nevion@… Owned by: reimar
Priority: normal Component: ao
Version: HEAD Severity: normal
Keywords: Cc: lennart@…, warren@…
Blocked By: Blocking:
Reproduced by developer: no Analyzed by developer: no


using pulseaudio 0.9.12-0.9.14 on opensuse 11.1 x86_64. Same story on ubuntu intrepid. Verified on both intel8x0 and intel-hda alsa drivers and several different computers, all of which are more than fast enough for the job...

mplayer, when playing a video with sound, freezes when unpaused - but comes back on seeking. Randomly occurs on seemingly any video with perhaps a higher probability when under load. Sometimes instead of completely freezing it stutters along and video/audio desync then play catchup for a moment.

Reported some time ago to PA bugtracker to see if it was their problem - they think it's mplayer's it would seem:

Attachments (1)

fprint.txt (22.8 KB) - added by nevion@… 11 years ago.
output of pa_stream_writable_size

Download all attachments as: .zip

Change History (18)

comment:1 Changed 11 years ago by reimar

The only useful comment there is by "thingwath" and it strongly indicates an issue in pulseaudio.
Furthermore, I have no issues with pulseaudio 0.9.9 on a 64 bit gentoo version.
Later versions I can't test because someone considered it a great idea to make pulseaudio depend on openrc and I am not ready to risk messing up my system that much.
Considering that there is a huge amount of complaints about pulseaudio for Ubuntu 8.10, for now I am not willing to do more than give the usual advise on the Ubuntu forums: get rid of pulseaudio as much as you can.

comment:2 Changed 11 years ago by reimar

I just testet with 0.9.14, and I can not reproduce the issue.
It does have a different issue though, pa_stream_get_latency has become very inaccurate (or it calculates something different than before, at least it has large "random" fluctuations), so you will have to use something like "-autosync 50" (that's one of the good old audio bug workarounds which for most people wasn't necessary for years).
This is using ubuntu and the intel hda driver, relevant dmesg output:
Advanced Linux Sound Architecture Driver Version 1.0.18rc3.
ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 20
HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 20 (level, low) -> IRQ 20
HDA Intel 0000:00:0e.1: setting latency timer to 64
ALSA device list:

#0: HDA NVidia at 0xfe020000 irq 20

comment:3 Changed 11 years ago by nevion@…

[Switching to thread 2 (Thread 0x7fc6adac9950 (LWP 6706))]#0 0x00007fc6b917b386 in poll ()

from /lib64/

(gdb) bt
#0 0x00007fc6b917b386 in poll () from /lib64/
#1 0x00007fc6c08be61d in ?? () from /usr/lib64/
#2 0x00007fc6c08b1179 in pa_mainloop_poll () from /usr/lib64/
#3 0x00007fc6c08b25e8 in pa_mainloop_iterate () from /usr/lib64/
#4 0x00007fc6c08b26b0 in pa_mainloop_run () from /usr/lib64/
#5 0x00007fc6c08be41d in ?? () from /usr/lib64/
#6 0x00007fc6c08e1720 in ?? () from /usr/lib64/
#7 0x00007fc6c2b0f070 in start_thread () from /lib64/
#8 0x00007fc6b918410d in clone () from /lib64/
#9 0x0000000000000000 in ?? ()
(gdb) thread 1
[Switching to thread 1 (Thread 0x7fc6c35c2840 (LWP 6705))]#0 0x00007fc6c2b161b1 in nanosleep ()

from /lib64/

(gdb) bt
#0 0x00007fc6c2b161b1 in nanosleep () from /lib64/
#1 0x00000000005f3e6e in usec_sleep (usec_delay=<value optimized out>) at osdep/timer-linux.c:25
#2 0x00000000004af179 in main (argc=0, argv=<value optimized out>) at mplayer.c:2373

I've triggered the bug and have gdb attached. What can I get you?

comment:4 Changed 11 years ago by reimar

The return value of pa_stream_writable_size might be interesting, a printf in the code probably is more useful than gdb for that though.
You could also try this patch, if it happens to work try to find out if it's the upper or the lower part that helps.
Index: libao2/ao_pulse.c
--- libao2/ao_pulse.c (revision 28650)
+++ libao2/ao_pulse.c (working copy)
@@ -171,6 +171,7 @@

pa_channel_map_init_auto(&map, ss.channels, PA_CHANNEL_MAP_ALSA);
ao_data.bps = pa_bytes_per_second(&ss);

+ ao_data.outburst = 2048;

pa_cvolume_reset(&volume, ss.channels);

@@ -306,7 +307,7 @@

l = pa_stream_writable_size(stream);

  • return l;

+ return l == 0 ? ao_data.outburst : l;


/ Return the current latency in seconds */

Changed 11 years ago by nevion@…

output of pa_stream_writable_size

comment:5 Changed 11 years ago by nevion@…

fprint of pa_stream_writable_size - sorry about the output not being locked and printed completely consistently.

It goes to zero when the bug is in effect (at the end).

comment:6 Changed 11 years ago by nevion@…

It seems it is the first (ao_data.outburst = 2048;) that fixes the behavior for me. I found how to test more reliably:

1)press pause then hold down the . (>) key. After a while it should sieze.
2)(less reliable than 1) press pause. leave it there for 10-20 secs, unpause and pause again... happens here more frequently than tapping pause/unpause constantly.

Interestingly enough in 1, even with the fix working, audio/video gets quite badly desynced.

comment:7 Changed 11 years ago by nevion@…

Oh yea, I forgot to mention, resumes are still sort of sticky - gets slow then speeds up fast for about 1-3 seconds of botched playing. (But at least it starts playing again without seeking,woooo!)

comment:8 Changed 11 years ago by reimar

The outburst change actually fixes nothing, it just makes it harder to spot.
For me the steps to reproduce are:
wait 5 seconds
The larger outburst, the longer you have to wait after pausing the first time to trigger the bug.
I applied a workaround that prints a warning and changes the way pausing is done, but it causes serious A-V desync after unpausing.

comment:9 Changed 11 years ago by nevion@…

So does this mean pulseaudio or mplayer is at fault? Or is it still unknown?

comment:10 Changed 11 years ago by reimar

I would say pulseaudio, but given that PulseAudio? is basically undocumented (particularly the pa_stream_cork function that is probably the cause has no documentation to speak of), how should I be able to tell? Maybe that function is _supposed_ to only work if you put your PC on Mt Everest and stand on you head, how should I know?

comment:11 Changed 11 years ago by lennart@…

This is now fixed upstream in PA. If a work-around for PA versions < 0.9.15 is required the best option would be to call pa_stream_trigger() right after uncorking.

comment:12 Changed 11 years ago by lennart@…

  • Cc lennart@… added

comment:13 Changed 11 years ago by dominik@…

Supposedly, this patch should be applied to MPlayer to fix this issue.

comment:14 Changed 11 years ago by lennart@…

(In reply to comment #12)

Supposedly, this patch should be applied to MPlayer to fix this issue.

Uh, no, that's a misunderstanding. This problem was fixed upstream in PA. The patch however removes the workaround in Mplayer for versions >= 0.9.15. It also fixes a couple of locking issue. (hence the name)

comment:15 Changed 11 years ago by warren@…

  • Cc warren@… added
  • Status changed from new to assigned
I can confirm that the combination of this pulseaudio fix plus mplayer-locking.patch makes mplayer work great again. Please apply.

comment:16 Changed 11 years ago by reimar

  • Resolution set to invalid
  • Status changed from assigned to closed

Hack disabled for 0.9.15 and newer.
No intention to improve the workaround, it will be removed once the distros had a chance to backport the fix.

comment:17 Changed 6 years ago by lameventanas

  • Analyzed by developer unset
  • Reproduced by developer unset
  • Resolution invalid deleted
  • Status changed from closed to reopened

I am experiencing the same thing, here are my symptoms:

  1. I play a movie with audio with mplayer -ao pulse
  2. mplayer reproduces the video and audio fine
  3. If I pause or seek, mplayer freezes and there is no way to make it come back. (In the original report, seeking fixed it).

This is with mplayer from 2014-02-06, and pulseaudio 5.0.

The system is a Linux 3.14.3 with pulseaudio 5.0 and mplayer 2014-02-06, everything 64-bit.

My soundcard is an Intel HDA with Realtek ALC889A.
Interestingly it works fine in another computer with Intel HDA and Realtek ALC269VC codec and similar software, could this be a driver issue?
I tested this kernel option, but it made no difference:

Version 0, edited 6 years ago by lameventanas (next)
Note: See TracTickets for help on using tickets.