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.
* 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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
