Thank you very much for clarification :)
Is there an anomaly somewhere: when sink_set_state() gets called by
pa_sink_suspend(), like this:
sink_set_state(s, pa_sink_used_by(s) ? PA_SINK_RUNNING : PA_SINK_IDLE);
sink_set_state() invokes s->set_state like this:
if ((ret = s->set_state(s, state)) < 0)
And it seems to call sink_input_set_state() according to my debug
messages (placed before and after s->set_state() invocation, and inside
of sink_input_set_state()). I suppose this is wrong because of
differences between PA_SINK_INPUT_* and PA_SINK_*? Or is this permitted?
_Ville
On 10.11.2014 21:19, Arun Raghavan wrote:
> On 10 November 2014 19:59, Ville Sundell <ville.sundell at nomovok.com> wrote:
>> Hello again!
>> I've traced the invocation of pa_sink_suspend(), and the erroneous uncorking
>> seems to lead to module-suspend-on-idle.so. Going to dig more into that.
> Right, so that uncorking is likely the culprit.
>
>> However, it seems that PA_SINK_SUSPENDED and PA_SINK_INPUT_CORKED are
>> accidentally sharing the same enum placement, could it be that situation
> PA_SINK_* and PA_SINK_INPUT_* enums are unrelated - their values may
> overlap, and it has no significance.
>
>> where suspending cause (s->suspend_cause) is 0, and sink is already
>> suspended, should be handled anyway? (just changing PA_SINK_INPUT_CORKED to
>> PA_SINK_SUSPENDED?)
> If s->suspend_cause is 0, that means all the causes to suspend the
> sink have gone away and that we should unsuspend the sink.
>
> Regards,
> Arun
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
