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.

_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Reply via email to