<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [regression] DYNAMIC_LATENCY introduced in module-combine causes a race contition between pa_sink_render_into_full and sink_update_requested_latency_cb in alsa-sink.c" href="https://bugs.freedesktop.org/show_bug.cgi?id=90489#c12">Comment # 12</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [regression] DYNAMIC_LATENCY introduced in module-combine causes a race contition between pa_sink_render_into_full and sink_update_requested_latency_cb in alsa-sink.c" href="https://bugs.freedesktop.org/show_bug.cgi?id=90489">bug 90489</a> from <a class="email" href="mailto:tanuk@iki.fi" title="Tanu Kaskinen <tanuk@iki.fi>"> Tanu Kaskinen</a> <pre>I looked a bit into this. The problem is that module-combine-sink can generate rewind requests during the sink input pop() callback. That should never happen. Each output struct has member inq, which is a message queue containing messages from the combine sink thread to the output thread. There are basically only two messages that are transmitted in that queue: POST and SET_REQUESTED_LATENCY. Processing a SET_REQUESTED_LATENCY message results in a rewind request. There are two places where the message queue may get processed during the pop() callback: render_memblock() and request_memblock() both call pa_asyncmsgq_process_one() in a loop to make sure the message queue has no buffered audio before requesting the combine sink to render more audio. If there is a SET_REQUESTED_LATENCY message in the queue when it's drained, this crash will happen. I think the queue draining code could be removed from both places without totally breaking things, but it might cause a situation where audio is rendered earlier than necessary. That might cause some issues. A safer fix would be to have two queues for the two messages. That way the SET_REQUESTED_LATENCY messages could be processed only when it's safe to do so. I'll hopefully get around writing a patch tomorrow.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>