[pulseaudio-discuss] How to differentiate pause and stop in pulseaudio.

[Tanu Kaskinen]

On Mon, 2020-06-15 at 09:15 +0000, Ramachandra Rao, Arun Kumar wrote:
> Hi Team,
> 
> 
> We have implemented a pulsemodule which listens on
> sink_input_new_hook and establishes connection with AudioManager and
> based on response from AudioManager, it sends PA_HOOK_OK or
> PA_HOOK_CANCEL.
> 
> 
> And we trigger Stream event request-cork/request-uncork from the
> pulsemodule to the corresponding sink_input, so that it reaches
> corresponding client application stream.
> 
> This is working perfectly fine for play and pause use-cases.
> 
> 
> But, we have also requirement to handle stop uses i,.e client
> application should be able to differentiate play/pause/stop events.
> 
> From our current understanding, the only way to notify client
> applications is through request-cork and request-uncork on stream
> events from server side.
> 
> On client side, those could be mapped like below.
> 
>   *   request-cork -> PAUSE
>   *   request-uncork -> PLAY/RESUME
>   *   ? -> STOP
> 
> Other possibilities we thought and also experimented to differentiate
> Stop from Pause are below:
> 
>   1.  Unlink the sinkinput from our pulsemodule side based on
> AudioManager policy decision.
>      *   [Concern] - This might lead to ungraceful notification on
> client side.
>      *   [Concern] - client application gets PA_STREAM_FAILED, which
> is difficult to differentiate whether it is stop or real stream
> failure at pulseaudio server side.
>   2.  We could either add/append custom property in the stream
> properties about the state(stop) - So, that the client-application
> can read this custom property from the stream and act accordingly.
>      *   [Concern] - Every client-application has to implement this
> specific handling in addition to cork/uncork handling.

Why is this concern specific to solution 2? Whatever you do, your
applications will need to have special handling for your special stop
event.

>      *   [Concern] - Still some sort of server-side trigger is
> required towards client so that, they could read this custom property
> of the stream.

When the proplist is updated, clients are notified through the
subscription system, unless you're updating the proplist directly
rather than using pa_sink_input_set_property() or other standard
proplist update functions.

>   3.  As stream events are actually textual information, we tried to
> send 'request-stop' for our use case. And this is transparently
> transmitted to applications as stream event.
>      *   This works fine for client applications that uses pulseaudio
> api directly.
>      *   [Concern] - This is problematic for applications that use
> GStreamer. because, we need to adapt GStreamer plugins for pulseaudio
> to handle this custom event 'request-stop'.

Again, I don't see how any solution can avoid special code in
applications or gstreamer or whatever component is handling the
communication with PulseAudio.

To me sending a cork-request event with the same system as the request-
cork event sounds like the simplest approach.

-- 
Tanu

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