An example from module-echo-cancel (repeated in all filter sinks):

static void sink_request_rewind_cb(pa_sink *s) {
    struct userdata *u;

    pa_sink_assert_ref(s);
    pa_assert_se(u = s->userdata);

    if (!PA_SINK_IS_LINKED(u->sink->thread_info.state) ||
        !PA_SINK_INPUT_IS_LINKED(u->sink_input->thread_info.state))
        return;

    pa_log_debug("Sink request rewind %lld", (long long) s->thread_info.rewind_nbytes);

    /* Just hand this one over to the master sink */
    pa_sink_input_request_rewind(u->sink_input,
                                 s->thread_info.rewind_nbytes, TRUE, FALSE, FALSE);
}


If s->thread_info.rewind_nbytes is zero (which it very well can be), then the pa_sink_input_request_rewind() call results in a full rewind, because pa_sink_input_request_rewind() treats zero as "as much as possible". There's actually no way to request a zero-byte rewind from sink inputs, so fixing this bug needs changes in the core too. But do zero-byte requests make any sense anyway? Yes, they do. The rewind processing is always initiated by the root sink, so every rewind request needs to be propagated to the root sink.

What are the practical consequences of this bug? At least this affects performance: doing a full rewind is a relatively heavy operation. I'm not sure if this can cause any glitches in the audio (other than risking underruns due to the full rewind). Having a quick look at pa_sink_input_process_rewind(), I would guess that the bigger-than-requested rewind won't cause any such issues, so unnecessary cpu-use spikes seem to be the only problem.