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
