[pulseaudio-discuss] Tracking lifetime of pa_context objects from API level

[Colin Guthrie]

'Twas brillig, and Marcel at 27/12/10 14:28 did gyre and gimble:
> I am seeking for an option to track the lifetime of pa_context objects.
> Unfortunately there in no callback when the reference counter reaches
> zero. It will only call pa_context free which is not visible to API users.
> 
> In fact, I am writing a C++ wrapper to the asynchronous API. And I want
> to start the (threaded) mainloop automatically. So the user need not to
> care about the mainloop at all. Well nothing special so far.

As someone who has written/adapted a couple of C++ related PA apps, I
can say that a good, generic, libpulse++ would be quite desirable. I'd
even be tempted to help out here if possible to help unify some of the
other stuff I've done.

One thing I would suggest doing (if you really are looking at a generic
lib) is to have a synchronous "test" method, to check if PA support is
available (e.g. try to connect to the server with a standard mainloop
that you run manually and then disconnect and reconnect with a proper
mainloop if PA support is available.

The reason for this approach is that PA support in the C++ apps I've
done, (kmix and phonon) is generally optional and based on the "if PA is
there, use it, otherwise fall back to ALSA" principles.

> But also I have to stop the main loop when it is no longer needed. This
> is not trivial, because the pa_context might only be referenced
> internally by other PA objects. So an instance counter of the C++
> context wrappers is not sufficient, because they might have gone out of
> scope while the mainloop is still needed for processing.
> 
> However, if I could track the total number of existing pa_context
> objects, I could safely stop the main loop after the last pa_context
> died. Without any pa_context object it is most likely no longer needed.

At what point do you need to cache the context objects? Most (all?)
callbacks include the context in them and as such you don't really need
to keep the context around as a variable in it's own right. Perhaps it
would be better

> The only available observable is the stat callback. But tracking changes
> to PA_CONTEXT_FAILED and PA_CONTEXT_TERMINATED is not sufficient. First
> of all a context might not have been used at all, Secondly a terminated
> connection might become connected later.

Contexts can only be used once, so if your context is TERMINATED or
FAILED, then it should be discarded and a new one used.

> Any ideas how to terminate the mainloop?

If you really do want to terminate the mainloop, then you should tear
down all contexts using it also I think.

Not sure if anything I've said helps specifically but perhaps seeing
some code would help to illustrate the problem better.

Happy to discuss things with you :)

Take care

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]