Hi, I'm debugging a program that uses pulseaudio simple API. The program is CPU-intensive and underruns occur from time to time. After some period of constant underruns, pa_simple_write() may hang forever. Here is the backtrace: #0 0x76d51a70 in __pthread_cond_wait (cond=0x22190, mutex=0x22170) at pthread_cond_wait.c:177 #1 0x76f783a4 in pa_threaded_mainloop_wait () from /usr/lib/arm-linux-gnueabihf/libpulse.so.0 #2 0x76f9b908 in pa_simple_write () from /usr/lib/arm-linux-gnueabihf/libpulse-simple.so.0 #3 0x00010b1c in main () I was able to reproduce this using a demo client that simulates underruns and high CPU usage: https://gist.github.com/gavv/9175515a9c3fb2539713212417c66a63 The gist contains the source code, logs, backtrace, and pactl output. The client log demonstrates that pa_simple_write() hanged at least for 5 minutes. I'm not sure if high CPU usage really matters, but it seems that it increases chances to catch a hang. Usage examples that reproduce the problem for me: # 10000 us busy loop after every 1024-byte write, 10 sec timeout ./a.out 10000 10 # 100000 us busy loop after every 1024-byte write, 10 sec timeout ./a.out 100000 10 This is reproducing on an ALSA sink, on pulseaudio 10.0 (from repository) and 11.1 (built from sources), both running on Raspberry Pi 3B (4x CPU ARMv7). It's not reproducing on my desktop. It's also not reproducing on a null sink. Just before the demo client hangs, pa_simple_get_latency() starts reporting zero latency. When the demo client hangs, all other clients connected to the same sink (e.g. mplayer) hang as well and there is no sound. If a new client is started then, all existing clients are resumed until the demo client hangs again. If the demo client is killed, all existing clients are resumed. Clients connected to other sinks are not affected. Here is a log for three clients (mplayer, sox play, and the demo client): https://gist.github.com/gavv/3e3f8e713b715defb4b083f5f6f27f1b
