[pulseaudio-discuss] Should corking be acknowledged by pa_sink_suspend()?

[Ville Sundell]

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