https://bugs.freedesktop.org/show_bug.cgi?id=88452
--- Comment #15 from David Henningsson <[email protected]> --- 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.
_______________________________________________ pulseaudio-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs
