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 <[email protected]> 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
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
