[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: how is pulseaudio supposed to work?



On Mon, 17.12.07 17:39, Richi Plana (myfedora richip dhs org) wrote:

> > 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.

The hotplug events come from HAL, so effectivel they are passed via
D-Bus.

There are a lot of external event sources PA acts on. If you really
want to have them all trigger "on-demand" launching of PA, then you'd
need a lot of "starter" programs everywhere. And PA would be started,
and stopped and started and stopped all the time. Certainly nothing
that helps user experience and performance of your system.

Handling audio is a long-running process and not just something that
is a short reaction on some other action. Also, those actions can come
very frequently. Thus, PA should be running all the time, and not only
when some action happens.

> 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.

inetd is dead. And I am dancing on its grave. Virtually no modern
network server software these days comes with inetd support enabled by
default anymore.

Also, things like inetd run as system daemon, not as user daemon. So,
if you want to start PA via such a system than you'd have to duplicate
inetd for the user. And not just inetd. Also HAL, Avahi, cron, X11...

Again. I really don't think that auto-spawning is what you want. There
are too many paths that might need to get PA started. 

Just think about one trivial thing: X11 integration. PA connects to
X11 to hook into a couple of events (bell, ...). In your model X11
would be starting PA everytime one of these events happen, across user
boundaries. Eerks! The X11 people would certainly love that! ;-)

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]