[pulseaudio-discuss] [PATCH v8] pipe-source: implement autosuspend option

[Georg Chini]

On 22.02.2018 09:49, Tanu Kaskinen wrote:
> On Thu, 2018-02-22 at 09:26 +0100, Georg Chini wrote:
>> On 21.02.2018 21:02, Georg Chini wrote:
>>> On 21.02.2018 20:15, Raman Shishniou wrote:
>>>> On 02/21/2018 09:41 PM, Raman Shuishniou wrote:
>>>>> 21.02.2018 20:07, Georg Chini пишет:
>>>>>> Maybe you misunderstood me. What I mean, is that the pipe can be
>>>>>> opened for writing as long as we are suspended. So it open when
>>>>>> we see that the source is suspended or when we auto suspend. Close
>>>>>> it as soon as the source gets unsuspended. This will avoid POLLHUP
>>>>>> during suspend completely. While auto suspended, we additionally have
>>>>>> to listen for POLLIN.
>>>>>> This way we can only get POLLHUP (or POLLIN with no data) when the
>>>>>> source is running.
>>>>>>
>>>>> I think I understand. We need to keep our writer opened while
>>>>> transition
>>>>> from autosuspended to opened state and just set events = 0.
>>> Exactly. I was also thinking about how to decide if data can be discarded
>>> or needs to be posted. On resume, the SET_STATE handler could set a
>>> just_unsuspended flag and when we know auto suspend is the only
>>> suspend cause, we can additionally set a resume_from_auto_suspend
>>> flag when we send the unsuspend message. In the thread function we
>>> could then check if
>>>
>>> just_unsuspended && resume_from_autosuspend -> post pending data,
>>> reset flags
>>> just_unsuspended && !resume_from_auto_suspend -> discard data, reset
>>> flags
>>> !just_unsuspended -> post data
>>>
>>> But that's only an idea.
>> It's even simpler, because the old and new suspend cause are available
>> in the
>> SET_STATE handler (or in the set_state_in_io_thread() callback). So
>> there we can
>> do:
>> if (old_cause == AUTO_SUSPEND && new_cause == 0) ->
>> resume_from_auto_suspend = true
>> else if (old_caue != 0 && new_cause == 0) -> resume_from_user_suspend = true
>>
>> BTW, maybe we should have a new suspend cause for that. Currently,
>> the best suspend cause we could use is PA_SUSPEND_UNAVAILABLE.
>> In the future however, it is planned, that streams get rescued when
>> the suspend cause is PA_SUSPEND_UNAVAILABLE and I guess that is
>> not what you want in your case.
> IIRC, we agreed that the stream rescuing will be done based on port
> availability, so the suspend state and cause will not be considered.

OK, my understanding was it would work like this:
No port -> set SUSPEND_UNAVAILABLE
If SUSPEND_UNAVAILABLE gets set -> rescue stream.
This would make it somewhat more generic and not alsa
specific. But I am OK with using the port availability directly.

>
> FWIW, I'm OK with using any of UNAVAILABLE, APPLICATION or some new
> suspend cause in the pipe source. I'd like to some day change the
> suspend system that the causes are identified by strings (in a hashmap)
> instead of enumeration values so that we don't have to pretend having
> some generic suspend causes when in reality each of them tends to be
> very specific to a particular piece of code.
>
I'd say the best fit in that case is PA_SUSPEND_UNAVAILABLE.