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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
