Finally, here is the fix, it turns out that gstreamer were asking for timeout that sometimes already happened. (maybe due to wakeups from pulse to update volume, anyway there is a check for such condition, but it is broken. pa_usec_t is unsigned, so a result of a subtraction will always be non negative, so, the following fixes this bug for me. or it is possible to make this a one liner patch by changing the type of 'usec' from pa_usec_t to int64_t --- Correctly deal with events in the past in calc_next_timeout From: Maxim Levitsky <maximlevitsky@xxxxxxxxx> pa_usec_t is unsigned, thus it will always be >= 0 This makes gstreamer pulse mixer work again --- src/pulse/mainloop.c | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/pulse/mainloop.c b/src/pulse/mainloop.c index c418d10..fb5f148 100644 --- a/src/pulse/mainloop.c +++ b/src/pulse/mainloop.c @@ -765,7 +765,7 @@ static pa_time_event* find_next_time_event(pa_mainloop *m) { static int calc_next_timeout(pa_mainloop *m) { pa_time_event *t; - pa_usec_t usec; + pa_usec_t clock_now; if (!m->n_enabled_time_events) return -1; @@ -776,12 +776,12 @@ static int calc_next_timeout(pa_mainloop *m) { if (t->time == 0) return 0; - usec = t->time - pa_rtclock_now(); + clock_now = pa_rtclock_now(); - if (usec <= 0) - return 0; + if (t->time < clock_now) + return 0; - return (int) (usec / 1000); /* in milliseconds */ + return (int) ((t->time - clock_now) / 1000); /* in milliseconds */ } static int dispatch_timeout(pa_mainloop *m) {