How to differentiate pause and stop in pulseaudio.

["Ramachandra Rao, Arun Kumar" <ARamachandraRao@xxxxxxxxxx>]

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.
   • [Concern] - Still some sort of server-side trigger is required towards client so that, they could read this custom property of the stream.
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.
   1. 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'.

Please provide your inputs or suggestions on this matter.

Any help would be highly appreciated.

Thank you

Regards,

Arun

---

This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you.

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