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
