2011-11-09 12:19, Colin Guthrie skrev: > 'Twas brillig, and Martin Steigerwald at 07/11/11 21:49 did gyre and gimble: >> 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? > This ins't really what was suggested. I haven't followed this thread closely, but I think this is a real use case and thus something we should officially support, and just not some very sparse but vocal minority. For me, I'm imagining something like a GUI where you can consciously assign one or more cards to be "system-wide" instead of "user-wide". That would in turn control consolekit/systemd and possibly other stuff that needs to be done to ensure that this card is to be used by the "pulse" user instead of the current user. We would also set up a system-wide instance for this card. The user-wide pulseaudio would be set up to talk to the system-wide one if present (presumably through a protocol-native tunnel? There are so many different ways of talking that I don't remember if there is a better one). Sure, the user would have to live with no SHM support - in most cases I assume this overhead would be quite neglible. Sure, recording can be eavesdropped, but if the user has made that choice in the first place, that would be a feature. This obviously needs integration with other projects and downstream distros, and trying to think with both hats on, I think PA upstream is better off with trying to make some recommendations for this use case, as the alternative would be to have distros doing things on their own and then being beat up by PA for doing things the wrong way. // David
