Am Montag, 7. November 2011 schrieb Maarten Bosmans: > 2011/11/7 Martin Steigerwald <ms at teamix.de>: > > Hi! Hi Maarten, hi, > > Before using Pulseaudio sound from both sessions has been played > > simultaneously with Phonon + Xine. Now I am using Phonon + GStreamer, > > but I bet stopping the audio comes from Pulseaudio. > > > > I read about system-wide mode. But first I shouldn't use it and > > second it doesn't solve this issue anyway, cause sound is still > > stopped. Maybe I missed setting autospawn on clients to off - cause > > I saw three pulseaudio daemons, one system-wide and two from the > > users -, but I do not like messing around with my Pulseaudio setup > > anymore - especially when its not recommended. Reason for trying > > Pulseaudio for me mostly was cause thats whats coming with Debian > > KDE standard install out of the box in the meanwhile. > > > > So whats the official way to achieve what I had before out of the > > box? The default per-session handling of audio makes sense for unix > > users being used by different human users on a shared computer but > > it does not make too much sense for my use case. > > I would load module-protocol-native-tcp with ip-acl=127.0.0.1. > Then for other users set PULSE_SERVER=localhost. Could this work with a three server setup: 1) one system-wide on 127.0.0.1 2) two session based ones that communicate with the system wide one? Or preferably not over TCP/IP at all but using unix sockets? Would this then solve the security issues mentioned on http://www.pulseaudio.org/wiki/WhatIsWrongWithSystemMode ? Please tell me when I am completely off track with that idea. Then feel free to skip answering the more detailed questions below. > Security: Much like the X server as soon as you are authenticated you > have complete control of the sound server, no further per-object access > checks are done. That should be solved, shouldn?t it? A networked server should look at permissions when other Pulseaudio daemons access it, right? But then it is needed to make sure, that the 127.0.0.1 or unix socket is the only way, the per session servers can access the system wide one. So users shall not be in the group for accessing the system wide pulseaudio server directly. > When in system mode, module loading after startup is disabled for > security reasons, which means: no hotplug handling in system mode Well as thats an option I could enable it again, given that the security issues are solved. > When in system mode, shared memory data transport is disabled for > security reasons, which means: much higher memory usage and CPU load in > system mode Same as above. > The module-xxx-restore modules maintain state that is inheritely user > specific, but when run in system mode is shared between users. I do not understand this one. > Security: there are no size limits on state data, which enables users to > flood /var unless you employ quotas on the pulse user Why? > Security: all users that have access to the server can sniff into each > others audio streams, listen to their mikes, and so on. This shouldn?t be possible with a networked system wide server, be it via TCP/IP or unix sockets. Right? > When in system mode you also lose a lot of further functionality, like > the bridging to jack, to rygel (upnp), to X11, to ckit, and so on What are the benefits of these? And which ones of these would be lost. Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
