https://bugs.freedesktop.org/show_bug.cgi?id=54779
--- Comment #6 from Tanu Kaskinen <[email protected]> 2012-09-16 07:40:30 UTC --- (In reply to comment #5) > Created attachment 67041 [details] [review] > Workaround for avoiding the live lock > > So in pa_rtpoll_run timeout for ppoll is calculated with micro-second > granularity and upscaled to nano-seconds for the actual ppoll call. > > Going deeper, time accounting is done via pa_rtclock_get and pa_timeval_cmp > which internally downscale nano-seconds to micro-seconds. > > This means if a sleep time is less than one micro-second, it will come out as > zero in pa_rtpoll_run. This will make the RT thread busy loop and thread live > lock on startup/shutdown. > > This workaround patch works for me by ensuring no busy loop happens if time > calculation did run and said zero sleep. > > Real patch would I assume be to change the pa_rtclock API to work with > timespec > (nano-seconds) instead of timeval (micro-seconds). That way this down-scaling > error would not happen. Thanks for the patch, and especially for the debugging! Is it clear to you why the rounding error causes the busy loop in the combine thread? I don't see why that would happen. -- 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. _______________________________________________ pulseaudio-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs
