Comment in the PA_SINK_MESSAGE_ADD_INPUT handler in sink.c:

/* We don't rewind here automatically. This is left to the
 * sink input implementor because some sink inputs need a
 * slow start, i.e. need some time to buffer client
 * samples before beginning streaming. */


Not doing the rewind automatically has led to a situation where every filter sink (and some other sink input implementations, like module-sine) has this sink input state change callback:

static void sink_input_state_change_cb(pa_sink_input *i, pa_sink_input_state_t state) {
    struct userdata *u;

    pa_sink_input_assert_ref(i);
    pa_assert_se(u = i->userdata);

    pa_log_debug("Sink input %d state %d", i->index, state);

    /* If we are added for the first time, ask for a rewinding so that
     * we are heard right-away. */
    if (PA_SINK_INPUT_IS_LINKED(state) &&
        i->thread_info.state == PA_SINK_INPUT_INIT) {
        pa_log_debug("Requesting rewind due to state change.");
        pa_sink_input_request_rewind(i, 0, FALSE, TRUE, TRUE);
    }
}


Repeating that in every filter sink shouldn't be needed. The core could request the rewind itself, without pushing the responsibility to the sink input implementors. Avoiding the rewind when it's not needed is only an optimization. In my opinion the optimization is good to have, but it could be implemented by having a sink input flag that says that this input "needs a slow start".