how is pulseaudio supposed to work?

[Roberto Ragusa]

Lennart Poettering wrote:

[snipped reasons about having PA as a session daemon]

> Admittedly there are a couple of drawbacks of PA being a session
> daemon. One being that it is very difficult to play an event sound
> while switching VTs on FUS. And sharing sound cards between multiple
> active sessions is difficult too. But I think these disadvantages do
> not  outweigh the advantages of the per-session design, far from
> that.

Technical reasons against system-wide mode apart, I realize that if
a daemon grabs the hardware in an exclusive way, but there are
reasonable use cases were many users want simultaneous access to the
hardware, maybe the daemon should be able to grant access to
those users by acting as an multiplexer in some way (well,
maybe mixer more than multiplexer).

Imagine this use case.

- There is a desktop session running, with moderate use of
audio (beeps, desktop sound effects, flash from a web site).

- Someone else in my room wants to play some mp3; so it logins
from another machine via ssh into the system to run mpg123.
The fact that some beeps could be mixed into the songs is
not an issue.

Now, the default PA configuration denies this, as the second user
(via ssh) is not the active session.

But, it is possible to grant permission to the second user.
I heard about cookie sharing; my self-discovered method
is to chmod 777 -R /tmp/pulse-myusername.

The sounds are now correctly mixed together, right?

Now, suppose the desktop session is going to be closed, but
the "remote" user still wants his music playing.
Closing the session will bring down the daemon, right?
It looks like there is no configuration to cope with this
scenario.

But a system wide daemon would manage this use case well.

Having in mind the strict desktop integration which can only
be achieved with the session based approach (I'm quoting
you), I simply wonder: why can't PA be a client of itself?
Why not have a system-wide PA *AND* one or more session-wide PAs?

I think that a PA hierarchy gives a lot of flexibility.
For example, in the Ctrl-Alt-F7, Ctrl-Alt-F8 use case described
in another mail, you could have the system-wide PA serving
the two session-wide PAs. Each of the session-wide could
decide if "mute sound when this session is switched out", but
the system-wide PA could also "ignore sound from any
child PA" or "lower volume to 10%" when the administrator
runs a specific command (imagine something triggered by,
for example, an ISDN event of a phone ringing) and a
firewall watching script could beep on specific events
and so on.

Considerations?

Best regards.

-- 
   Roberto Ragusa    mail at robertoragusa.it