[pulseaudio-discuss] How to differentiate pause and stop in pulseaudio.
tanuk at iki.fi
Mon Jul 6 09:30:33 UTC 2020
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
> 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
> * [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.
More information about the pulseaudio-discuss