[pulseaudio-discuss] pulseaudio timing out accepting connections

[Lennart Poettering]

On Wed, 10.12.08 09:44, Brian J. Murrell (brian at interlinx.bc.ca) wrote:

> My pulseaudio server seems to be hung up (spinning in fact).  paplay has
> this to say:
> 
> $ paplay /mnt/mp3/bad_mouth.wav 
> Connection failure: Timeout
> 
> A backtrace of pulseaudio right now shows it at:
> 
> Thread 4 (Thread 0xb738eb90 (LWP 13179)):
> #0  0xb80c4430 in __kernel_vsyscall ()
> #1  0xb7c431b4 in ppoll () from /lib/tls/i686/cmov/libc.so.6
> #2  0xb806ecee in pa_rtpoll_run (p=0x8d778c0, wait=true)
>     at pulsecore/rtpoll.c:394
> #3  0xb74b1bb5 in thread_func (userdata=0x8d773a8)
>     at modules/module-alsa-sink.c:642
> #4  0xb8072842 in internal_thread_func (userdata=0x8d80998)
>     at pulsecore/thread-posix.c:73
> #5  0xb7cd050f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
> #6  0xb7c4d7ee in clone () from /lib/tls/i686/cmov/libc.so.6
> 
> Thread 3 (Thread 0xb6b8db90 (LWP 13180)):
> #0  0xb80c4430 in __kernel_vsyscall ()
> #1  0xb7cd710b in read () from /lib/tls/i686/cmov/libpthread.so.0
> #2  0xb806bf83 in pa_fdsem_wait (f=0x8d82b00) at /usr/include/bits/unistd.h:45
> #3  0xb806b0a3 in pa_asyncq_push (l=0x8d83758, p=0xb6258970, wait=1)
>     at pulsecore/asyncq.c:132
> #4  0xb806a6c1 in pa_asyncmsgq_post (a=0x8d82c70, object=0xb6202540, code=0, 
>     userdata=0x0, offset=0, chunk=0xb6b8d30c, free_cb=0)
>     at pulsecore/asyncmsgq.c:139
> #5  0xb74eccdc in source_output_push_cb (o=0xb6228c38, chunk=0xb6b8d30c)
>     at pulsecore/protocol-native.c:1116
> #6  0xb8065e91 in pa_source_output_push (o=0xb6228c38, chunk=0xb6b8d30c)
>     at pulsecore/source-output.c:341
> #7  0xb80624b7 in pa_source_post (s=0x8d93b18, chunk=0xb6b8d30c)
>     at pulsecore/source.c:302
> #8  0xb749bc73 in thread_func (userdata=0x8d70758)
>     at modules/module-alsa-source.c:179
> #9  0xb8072842 in internal_thread_func (userdata=0x8d94268)
>     at pulsecore/thread-posix.c:73
> #10 0xb7cd050f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
> #11 0xb7c4d7ee in clone () from /lib/tls/i686/cmov/libc.so.6

This is a known deadlock in 0.9.10 which can be triggered if due to
some reason the IO ("RT") threads get scheduled a *lot* more than the
main thread. Usually this means you have a lot of sound cards
configured and/or some weird low-quality kernel with closed-source
drivers that fuck up process scheduling. (i.e. ubuntu)

This has been fixed in newer PA versions.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4