On Sat, 2013-12-14 at 14:25 +0530, sathishkumar sivagurunathan wrote: > Thanks Tanu for the reply, > > I have been trying to some simple analysis for the past on this question > below I raised before you last time.. > > 1) I have a routing policy manager which would like to cork/pause a > stream. No priority is involved in this usecase. Is it this possible with > Pulse Audio. > > Only the application that created the stream can cork it. External > policy managers can't do that. This may change in the future, but don't > count on that. If you want to implement a policy for corking streams, > you have to do that in a PulseAudio module. > > Tanu, I understand that it is possible only by the application to cork the > stream. I really tried using the "module-role-cork" module. > But I couldn't fit it into my need for having called from my policy > manager.. > > Hence, I was trying to go through the code if something different can be > done. I had presented my analysis to you. Glad to hear your comments on > it.. > > My idea is (though my analysis might not be perfect) :- > > 1) I looked at the available C API's that are available in Instrospect.c. > It houses the C API's to be called for muting, changing volume etc. > Is it possible to add a function to this Introspect.c for pause > functionality. > > 2) I also saw that C API's in Introspect.c like called functions in > protocol-native.c to execute the functionality. > Example:- *pa_context_set_sink_mute_by_index* function in Introspect.c > calls *command_set_mute *in protocol-native.c. > > 3) Hence is it possible to write a new function for pause say " > *pa_context_set_sink_input_pause*" in Introspect.c and call " > *command_set_pause*" in protocol-native.c. About the function naming: "pause" isn't a good term, because we already use the term "cork" that means the same thing. Also, "set_sink_input_cork" isn't good, because you only send a request to the client, you don't set the cork state directly. Perhaps "pa_context_request_sink_input_cork()" would be good? > 4) This new function "*command_set_pause*" in protocol-native.c calls > into "*pa_sink_input_send_event" > *in sink-input.c and henceforth the event is relayed to the application for > pausing. > > 5) Indeed I am just trying to use the same chain of command followed by " > *module-role-cork*" module to relay command which is > * module-role-cork* -> *pa_sink_input_send_event* in sink-input.c -> > *sink_input_send_event_cb* in protocol-native.c -> Application --> which > instructs to pause. > > 6) I am just to come from the Introspect.c side.. > *pa_context_set_sink_input_pause *in Introspect.c -> *command_set_pause > *in protocol-native.c -> *pa_sink_input_send_event* in sink-input.c -> > *sink_input_send_event_cb* in protocol-native.c -> Application --> which > instructs to pause. > > My questions are:- > > Is this feasible.. I am asking this because i trying to connect as a client > and do it. And you had mentioned that client would be allowed to do such a > thing.. It's feasible. I don't know if it's a good idea, though. I think it's asking for trouble to do audio policy enforcement relying only on an external component, because there will always be able things that you can't control from outside the server, things like the initial routing and volume of a new stream. I'm working myself on bringing Murphy support to PulseAudio. Murphy is an external policy manager, but it will also have a dedicated module in PulseAudio. I will need to handle corking policy too, but I don't know yet the details about how that will be handled (I've been working on routing policy so far). I'm pretty sure it will not be handled via the introspect.h API, however. Murphy won't use PulseAudio's client API, as far as I know. Instead, the Murphy module in PulseAudio will be a client to Murphy, using Murphy's APIs, so the client-server relationship is the other way around than in your setup. If you send patches for adding pa_context_request_sink_input_cork() anyway, I won't reject those. While I think you're likely to regret the decision to use an external policy manager that only uses the client API, I don't have proof that it won't be good enough for your purposes, so I shouldn't block this feature. -- Tanu
