how is pulseaudio supposed to work?

[Richi Plana]

On Tue, 2007-12-18 at 00:48 +0100, Lennart Poettering wrote:
> On Sun, 16.12.07 09:46, Richi Plana (myfedora at richip.dhs.org) wrote:
> 
> > Again, ideally, services (including system ones) should 1) only be
> > started and 2) actually be started when it is called for. Something
> > similar to the way kernel modules are autoloaded when there's a need for
> > the service. Or xinetd does for some services which use it (though with
> > an option to actually stay resident).
> 
> Besides (very few) exceptions, kernel drivers are nowadays loaded when
> the hardware they driver becomes available -- and not only when they
> are used. 
> 
> You can configure PA so that it is autospawned when needed. However, I
> do not recommend this. I recommend to start it from the session
> manager like we do it right now for KDE and GNOME. Why? Because PA
> nowadays does much more than just proxying access to the hw. It reacts
> on hotplug events, network configuration changes, certain X11 events,
> it is a network server, and so on and so on. For all these reasons it
> is better to leave PA running all the time.

But how are those hotplug events communicated? That's what I meant when
I said the pulseaudio sound server should be started on an as-needed
triggering event. If there are too many entry paths to using PA, then I
understand the complexity.

What's the underlying communication mechanism for event passing? D-Bus?
TCP communication? For TCP sessions, we have xinetd. Would there be an
interest in having a similar service for spawning object / services as a
result of D-Bus service requests? Or is there already an existing
infrastructure? Now I'm just curious.
--

Richi Plana