> > Hi , > > I am trying to add a new function "pa_context_set_sink_input_paused" to the pulseaudio introspect.c file. I was able to able and successfully compile pulseaudio too.. > > gcc pa_listclients_pause.c -o pa_listclients_pause -L /home/sathish/Desktop/pulseaudio-4.0/build/src/.libs/ -lpulse > > /tmp/ccueP47b.o: In function `pa_get_devicelist': > > pa_listclients_pause.c.text+0x6cb): undefined reference to `pa_context_set_sink_input_paused' > > collect2: error: ld returned 1 exit status > > But when I try to run a program using this new function, it returns me "undefined reference". > > I tried to run the nm command and check whether the new function is present in libpulse.so > > The function returns me it has found it.. > > nm -A *.so | grep "pa_context_set_sink_input_paused" > > libpulse.so:0001d4a0 t pa_context_set_sink_input_paused > > I am not able to comprehend what is happening. Can you help me with this ?? > > Thanks, > > Sathish > > > > From: Sathishkumar Sivagurunathan > Sent: Thursday, December 19, 2013 2:24 PM > To: 'sathishkumar sivagurunathan' > Subject: RE: Re: [pulseaudio-discuss] Pause a audio stream > > > > Hi Tanu, > > > > Thanks for the reply and advice, > > > > 1) My current aim is just short term. Hence I would just like to have pause implemented through the introspect.h as a first step. > > > > In accordance with my previous mail, I had made the changes to the necessary files and compiled using the "make". But somehow when I run my c program which calls the function “pa_context_request_sink_input_cork()”, it seems to not pick up the new function defined in introspect.c. It returns a undefined reference error.. > > > > The command I used for compiling the program I am using to call the cork functionality points lpulse library. > > > > Is there something other than "make" I should be looking at ?? > > > > The compilation of PulseAudio with the changes was successful without any errors.. > > > > 2) But if you can help me understand this client - server concept, I will try to take as the next step. My doubts in this are pretty elementary but it will help me a lot if you can clear them. > > > > a) "Murphy is an external policy manager, but it will also have a dedicated module in PulseAudio." > > > > The one I am working on is similar to Murphy. When you say, we will have a dedicated module, should this module be like the other modules like "module-role-cork" ?? > > > > b) "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." > > > > Now, Murphy module in PulseAudio is client, Murphy is the server. How will the murphy api's in the client will be called. Will it be through the "load-module" functionality currently available with pactl, loaded by pulseaudio at daemon start up or like a C function call.. > > > > In short, it would be great if you can help understand how the communication between these three thing takes place ?? > > > > Murphy --> Murphy module in PulseAudio () --> PulseAudio.. > > > > Thanks, > > Sathish > > > > From: sathishkumar sivagurunathan [mailto:<a href="mailto:sathish1000@gmail.com">sathish1000@gmail.com</a>] > Sent: Thursday, December 19, 2013 12:19 PM > To: Sathishkumar Sivagurunathan > Subject: Fwd: Re: [pulseaudio-discuss] Pause a audio stream > > > > ---------- Forwarded message ---------- > From: "Tanu Kaskinen" <<a href="mailto:tanu.kaskinen@linux.intel.com">tanu.kaskinen@linux.intel.com</a>> > Date: Dec 16, 2013 4:18 PM > Subject: Re: [pulseaudio-discuss] Pause a audio stream > To: "sathishkumar sivagurunathan" <<a href="mailto:sathish1000@gmail.com">sathish1000@gmail.com</a>> > Cc: <<a href="mailto:pulseaudio-discuss@lists.freedesktop.org">pulseaudio-discuss@lists.freedesktop.org</a>> > > 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 >