[pulseaudio-tickets] [Bug 88452] pulseaudio "killed" my qemu instance (assertion hit)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=88452

--- Comment #15 from David Henningsson <david.henningsson at canonical.com> ---
Ok, reproduced here.

First. Qemu asks for a very low latency:

D: [lt-pulseaudio] protocol-native.c: Requested latency=0,01 ms, Received
latency=0,50 ms

0,01 ms, that's half (!) of one sample. I wonder why qemu does that...

Even if we add that up to 0,50 ms that's still very low, even if gets a bit
larger later due to overruns.

Second. Qemu starts up a recording stream, asking pulseaudio to write packets
to it. But it does not release any packets in a timely fashion. So the 128
slots quickly fill up. That's when PulseAudio starts to send audio packets over
the srbchannel as a fallback/workaround.

Third. It's when the srbchannel gets full that "interesting" things start to
happen. When not the entire packet can be written at a time, it might also be
read in chunks, depending on timing. However, if only part of a memblock is
available, it is being split up - with no respect to frame boundaries - in
do_read (right below /* Frame payload available */ ). This is the main culprit.

Fourth. There is an mcalign layer that can sometimes fix this, but not always.
The problem is here that since the queue is so filled up, only some packets get
pushed into the queue. If a memblock gets split in two in the previous step,
and only the latter of them gets into the queue (e g because it is much smaller
than the first), then the latter one will start at an index which is not a
frame boundary, and the program will crash.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-bugs/attachments/20150213/20c02655/attachment.html>