[pulseaudio-tickets] [Bug 54185] New: Filter sinks (and sources?) handle rewind requests of 0 bytes wrong

[bugzilla-daemon at freedesktop.org]

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

             Bug #: 54185
           Summary: Filter sinks (and sources?) handle rewind requests of
                    0 bytes wrong
    Classification: Unclassified
           Product: PulseAudio
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: modules
        AssignedTo: pulseaudio-bugs at lists.freedesktop.org
        ReportedBy: tanuk at iki.fi
         QAContact: pulseaudio-bugs at lists.freedesktop.org
                CC: lennart at poettering.net


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.

-- 
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.