[pulseaudio-discuss] pulseaudio timing out accepting connections

Wed Dec 10 07:01:21 PST 2008

Hi,

On Wed, Dec 10, 2008 at 9:44 AM, 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

Are you running PA in realtime mode? Does top say that its priority is "RT"?

> #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

Looks like a read loop in the message processing thread - this looks ok.

> #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
>
> Thread 2 (Thread 0xb61ffb90 (LWP 9228)):
> #0  0xb80c4430 in __kernel_vsyscall ()
> #1  0xb7c431b4 in ppoll () from /lib/tls/i686/cmov/libc.so.6
> #2  0xb806ecee in pa_rtpoll_run (p=0xb6231c10, wait=true)
>    at pulsecore/rtpoll.c:394
> #3  0xb74b1bb5 in thread_func (userdata=0xb6201918)
>    at modules/module-alsa-sink.c:642
> #4  0xb8072842 in internal_thread_func (userdata=0xb6235690)
>    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 1 (Thread 0xb7b29920 (LWP 13178)):
> #0  0xb80c4430 in __kernel_vsyscall ()
> #1  0xb7cd6405 in sem_wait@@GLIBC_2.1 ()
>   from /lib/tls/i686/cmov/libpthread.so.0
> #2  0xb8072a38 in pa_semaphore_wait (s=0x8d81270)
>    at pulsecore/semaphore-posix.c:65
> #3  0xb8069f6d in pa_asyncmsgq_send (a=0x8d83138, object=0x8d93b18, code=6,
>    userdata=0xbfac37f8, offset=0, chunk=0x0) at pulsecore/asyncmsgq.c:169
> #4  0xb8061f58 in pa_source_get_latency (s=0x8d93b18) at pulsecore/source.c:318
> #5  0xb74f43c8 in command_get_record_latency (pd=0xb6220558, command=57,
>    tag=645, t=0xb6220980, userdata=0xb6229818)
>    at pulsecore/protocol-native.c:1777
> #6  0xb74cba99 in pa_pdispatch_run (pd=0xb6220558, packet=0xb622b540,
>    creds=0x0, userdata=0xb6229818) at pulsecore/pdispatch.c:241
> #7  0xb74ef1b2 in pstream_packet_callback (p=0xb62619b0, packet=0xb622b540,
>    creds=0x0, userdata=0xb6229818) at pulsecore/protocol-native.c:3105
> #8  0xb74d502b in do_something (p=0xb62619b0) at pulsecore/pstream.c:818
> #9  0xb7506488 in callback (m=0x8d7268c, e=0xb625eb50, fd=58,
>    f=<value optimized out>, userdata=0xb6250a98) at pulsecore/iochannel.c:121
> #10 0xb801fd49 in pa_mainloop_dispatch (m=0x8d72648) at pulse/mainloop.c:679
> #11 0xb80200a1 in pa_mainloop_iterate (m=0x8d72648, block=1, retval=0xbfac3b04)
>    at pulse/mainloop.c:922
> #12 0xb8020164 in pa_mainloop_run (m=0x8d72648, retval=0xbfac3b04)
>    at pulse/mainloop.c:937
> #13 0x0805118d in main (argc=3, argv=0xbfac3bb4) at daemon/main.c:812
>
> dpkg says I'm using 0.9.10-2ubuntu9.1 (which is probably your 0.9.10
> release) and I'm on Ubuntu Intrepid.
>
> I still have it running if there is any more information I can gather.

Yeah, it sounds like PA is stuck in a tight loop trying to access
ALSA. I've never encountered this before, and I've used Intrepid a
bit. I'm thinking either you have a custom compiled version of a
library that PA depends on; or, you have some strange hardware.

Can you tell me what kinds of applications are currently active as
sinks on your PA? What protocol are they connecting through? Any
ALSA<->Pulse apps? Just as data points. Also, post an lspci (and also
an lsusb if you have a USB soundcard).

>
> Otherwise, I guess I need to restart it.  After I kill it and run
> another with say, the gnome-run tool (or in a terminal), will all of the
> clients (i.e. ESD clients, firefox, etc.) reconnect to the new server
> instance?

Nope, there's no guarantee of that. Clients have control over the
terms under which they try to connect to PA. If they're trying to
communicate and they're timing out, they might decide to give up; if
they connect and get an error, they may also give up and refuse to
proceed. With some apps you may have to restart them. Others might
just keep a full buffer of audio and unload it as soon as they can get
back into PA.

-Sean

>
> Thanx,
> b.
>
>
>
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>