pulseaudio and mplayer sticky pause

[nevion@…]

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: ​http://www.pulseaudio.org/ticket/440

[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.

[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

[nevion@…]

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

from /lib64/libc.so.6

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

from /lib64/libpthread.so.0

(gdb) bt
#0 0x00007fc6c2b161b1 in nanosleep () from /lib64/libpthread.so.0
#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?

[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 @@

pa_threaded_mainloop_lock(mainloop);
l = pa_stream_writable_size(stream);
pa_threaded_mainloop_unlock(mainloop);

• return l;

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

}

/ Return the current latency in seconds */

[nevion@…]

output of pa_stream_writable_size

[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).

[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.

[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!)

[reimar]

The outburst change actually fixes nothing, it just makes it harder to spot.
For me the steps to reproduce are:
pause
wait 5 seconds
frame-step
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.

[nevion@…]

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

[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?

[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.

[Dominik 'Rathann' Mierzejewski]

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

​http://0pointer.de/public/mplayer-locking.patch

[lennart@…]

(In reply to comment #12)

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

​http://0pointer.de/public/mplayer-locking.patch

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)

[warren@…]

​http://www.pulseaudio.org/ticket/440
I can confirm that the combination of this pulseaudio fix plus mplayer-locking.patch makes mplayer work great again. Please apply.

[reimar]

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.

[lameventanas]

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). Sometimes instead of freezing it stutters for a while, but pausing/seeking again will freeze it. Audio-only files don't have this problem.

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:
CONFIG_SND_HDA_PREALLOC_SIZE=2048