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

[Tanu Kaskinen]

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.

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.

-- 
Tanu

https://liberapay.com/tanuk
https://www.patreon.com/tanuk