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. However, it seems that PA_SINK_SUSPENDED and PA_SINK_INPUT_CORKED are accidentally sharing the same enum placement, could it be that situation 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?) _Ville On 07.11.2014 11:10, Ville Sundell wrote: > Thank you for the pointers, I will check these points and let you guys > know :) > > _Ville > > On 07.11.2014 09:13, Arun Raghavan wrote: >> On 5 November 2014 15:44, Ville Sundell <ville.sundell at nomovok.com> >> wrote: >>> On 05.11.2014 11:57, Arun Raghavan wrote: >>>> On 5 November 2014 15:04, Ville Sundell <ville.sundell at nomovok.com> >>>> wrote: >>>>> Greetings everyone! >>>>> I am having some problems with corking: pulseaudio policy enforcer >>>>> will >>>>> cork >>>>> all the streams which belongs to a corked group. However, despite the >>>>> fact >>>>> corking itself happens correctly (via pa_sink_input_cork() at >>>>> pulseaudio-policy-enforcement:src/policy-group.c) the stream will >>>>> not end >>>>> up >>>>> being corked, instead it will be set to PA_SINK_RUNNING. >>>> Not sure what code base this is, but this policy enforcement is not >>>> part of PulseAudio upstream. I guess this comes from Nemo or Tizen? >>> That is true, policy enforcer is implemented as a PulseAudio module, >>> and is >>> used by Nemo and other similar systems. >>>> >>>> Either way, there seems to be some confusion between concepts here. >>>> The idea of corking applies to sink inputs (pa_sink_input on the >>>> server side, pa_stream on the client side). The idea of being >>>> suspended applies to sinks (pa_sink). Could you explain your problem >>>> again, and what the symptoms are, keeping this in mind? >>> Thank you for clarifying this! The problem is as follows: >>> 1) Program, which is part of a group which is already corked, opens >>> a stream >>> 2) Policy enforcer notices this, and corks the stream right away, >>> like this: >>> pa_sink_input_cork(si, group->corked); >>> 3) PulseAudio corks the stream correctly, up to this point >>> everything works >>> as expected >>> 4) However, pa_sink_suspend() gets called without a cause >>> (s->suspend_cause), it tries to return it to a normal state >>> (PA_SINK_RUNNING >>> or PA_SINK_IDLE), but here the state should be and stay as >>> SINK_INPUT_CORKED >> It would be good to see what the call stack leading to >> pa_sink_suspend() is. Please note again that PA_SINK_INPUT_CORKED is >> not a state that applies to a sink. The sink would either be in >> PA_SINK_SUSPENDED or _IDLE or _RUNNING. >> >>> 5) This will lead to uncorking of the stream which should be corked >>> (after >>> applying the attached patch, this stream stays corked) >> Changes in sink state should not cause sink inputs to uncork under the >> normal course of events (I haven't looked at your policy enforcement >> code, so don't know if that's triggering something). >> >> Regards, >> Arun >> _______________________________________________ >> pulseaudio-discuss mailing list >> pulseaudio-discuss at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > > _______________________________________________ > pulseaudio-discuss mailing list > pulseaudio-discuss at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
