[pulseaudio-discuss] I want to know about how to communication one module with another module

[Tanu Kaskinen]

On Wed, 2012-07-25 at 23:21 +0800, rong deng wrote:
> Hi Zhen,
> 
> 2012/7/24 Zhen Fu <fuzh at marvell.com>:
> > Hi all developer,
> >
> >
> >
> > I want to know about how to communication one module with another module. Is
> > it use asyncmg? Thank you!

No, the asyncmsgq stuff is not a generic inter-module communication
method. It's a method for communicating between threads (which may be
handled by different modules, though).

There's no messaging system specifically for communication between
modules. There are different ways to do the communication, depending on
what you're doing.

> I'm not the expert here, but here's my two cents. :)
> 
> In theory, two modules should not communicate directly with each
> other.

I don't think it's that strict. You're right in asking for the reason
for wanting to communicate between modules, though. If it can be avoided
in a nice way, then it should be avoided, but there are valid cases
where a set of modules need to collaborate using custom interfaces (I'll
give some examples later).

> For a module, the only thing it should care about is the core,
> and it should communicate with the core, handling the messages from
> the core etc. As you might know already, pulseaudio takes the thread
> model, for most of the modules, they would reside in a separate
> thread, e.g. ALSA. Communicating directly with two methods could be a
> mess, and even worse, one module is totally unaware when the another
> module is loaded or not.

Threading is created mostly (perhaps even only) in modules that
implement sinks and sources. Threads are used there, because the main
thread of pulseaudio isn't suitable for real-time audio processing. In
other modules (that I believe are actually the majority) the code runs
in the main thread. Life is much simpler that way.

> So the current way, in my humble opinion, is to use the core as a
> bridge to direct the communication between two modules.

That's one way to do it. For example, the native protocol and the D-Bus
protocol modules both have a component in pulsecore
(src/pulsecore/protocol-native.c and src/pulsecore/protocol-dbus.c) that
implement the interfaces for communicating between modules that want to
use those protocols and the modules that implement the protocol.

The model in this case is to create a reference counted singleton object
(pa_native_protocol and pa_dbus_protocol) when any module wants to use
that functionality. The singleton object will then exist as long as
there are users for it, and it's freed when the last module using it is
unloaded.

That's a bit ugly in my opinion, because it bloats libpulsecore with
non-core things.

A similar model is used in the bluetooth modules, for doing interaction
between the modules, but there the singleton object
(pa_bluetooth_discovery) is not implemented in libpulsecore, but in
libbluetooth-util instead.

There has been some plans for creating a bit of infrastructure for
helping with inter-module communication:
http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/9315/focus=9474

I think Frédéric Dalleau planned to start working on this some time ago,
but I'm not sure if he had time for it after all. Frédéric, could you
clarify the status of this?

-- 
Tanu