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 <[email protected]>
wrote:
On 05.11.2014 11:57, Arun Raghavan wrote:
On 5 November 2014 15:04, Ville Sundell <[email protected]>
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
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
_______________________________________________
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
