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
