[pulseaudio-tickets] [Bug 54779] Live lock on daemon startup when module combine is used and real time scheduling is enabled

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Sep 17 03:44:26 PDT 2012


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

--- Comment #8 from Tanu Kaskinen <tanuk at iki.fi> 2012-09-17 10:44:26 UTC ---
I'm asking why there is a busy loop in the first place. I have looked at the
module-combine-sink IO thread code in detail, and I don't understand why your
fix helps the situation.

Regarding the fix in general, I don't think sub-microsecond rounding errors in
pa_rtpoll_run() should cause problems in the calling code, so I think
module-combine-sink should be fixed instead of fixing pa_rtpoll_run(). The fix
is still very interesting, because it works even though it looks to me like it
shouldn't be needed.

My main suspicion is that this code is the problem:

    if (!u->thread_info.in_null_mode || u->thread_info.timestamp <= now)
        process_render_null(u, now);

If the "now" variable stays below the timestamp for a prolonged time, then
there can be a busy loop. If your fix helps the situation, I think it means
that the difference of now and the timestamp is only one microsecond. The "now"
variable is updated in every loop iteration with pa_rtclock_now(), so the busy
loop shouldn't last for longer than one microsecond (which I think is not
enough to get the process killed). Maybe pa_rtclock_now() may actually be less
granular than one microsecond, so the busy loop can last longer because
pa_rtclock_now() keeps returning the same value for a longer time?

I think this sort of issues could be avoided by not having a strict "timestamp
<= now" check here, and instead fill the imaginary buffer even when it's not
completely empty. I will make a patch doing that soon, so you can test it, but
I'd really like to understand why exactly the busy loop happens, instead of
having just vague guesses.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the pulseaudio-bugs mailing list