[pulseaudio-discuss] pa_simple_write() hangs after underruns

[Victor]

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

From the user perspective, I see two problems here:

 - I see no reliable way to prevent a hang after an underrun, at least
   using the simple API (except checking whether
   pa_simple_get_latency() returns zero, but I'm not sure if this is
   reliable).

 - Underruns in a badly written client cause hangs in other clients.

Not sure if there is an opened bug for this (I didn't find one..), so
posting it here. Please let me know if I can provide any more details.

-- Victor