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 _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
