Bug 54185 - Filter sinks (and sources?) handle rewind requests of 0 bytes wrong
Filter sinks (and sources?) handle rewind requests of 0 bytes wrong
Status: NEW
Product: PulseAudio
Classification: Unclassified
Component: modules
unspecified
Other All
: medium normal
Assigned To: pulseaudio-bugs
pulseaudio-bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-29 06:18 UTC by Tanu Kaskinen
Modified: 2012-08-29 06:18 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tanu Kaskinen 2012-08-29 06:18:12 UTC
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.