[pulseaudio-discuss] 61ms delay in pa_simple_write()

[Wu Fengguang]

Greetings,

We are debugging a new QEMU USB audio model that works fine with alsa
backend but drops samples from time to time with pulseaudio backend.

Traces show that the pa_simple_write() call normally does its job
quickly, but sometimes takes ~60ms to return (the last write=XXms
field):

    L1    qpa_thread_out rpos = 1499, pa->decr = 1155, decr = 1155, pa->live = 0, write=0ms
    L2    qpa_thread_out rpos = 605, pa->decr = 1154, decr = 1154, pa->live = 0, write=0ms
    L3    qpa_thread_out rpos = 1670, pa->decr = 1065, decr = 1065, pa->live = 0, write=1ms
    L4    qpa_thread_out rpos = 736, pa->decr = 1114, decr = 1114, pa->live = 0, write=0ms
    L5    qpa_thread_out rpos = 1850, pa->decr = 1114, decr = 1114, pa->live = 0, write=0ms
    L6    qpa_thread_out rpos = 957, pa->decr = 1155, decr = 1155, pa->live = 0, write=0ms
    L7    qpa_thread_out rpos = 15, pa->decr = 1106, decr = 1106, pa->live = 0, write=0ms
==> L8    qpa_thread_out rpos = 1127, pa->decr = 1112, decr = 1112, pa->live = 936, write=61ms
==> L9    qpa_thread_out rpos = 1127, pa->decr = 2048, decr = 2048, pa->live = 0, write=0ms

The 61ms delay in L8 overruns the ring buffer inside qemu (note the
decr=2048 in L9; I ran qemu with QEMU_PA_SAMPLES=2048).

Skimming through the pulseaudio code, my wild guess is there are two
possible source of delays (I excluded kernel problems since ALSA works
fine):
1) memory allocation
2) pulseaudio internal lock
3) blockable syscall

I'm mainly suspecting (1). Basically any latency sensible application
should do pre-allocation and to _absolutely avoid_ memory allocation
during audio streaming. However I do see the pa_simple_write() calls
into pa_stream_write() which in turn _might_ call malloc() in the end.

I'm not sure if the pa_memblock_new[_user]() API takes care to
preallocate _enough_ memory before playback. Can anyone kindly confirm
that?

Thanks,
Fengguang