[pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions

[Colin Guthrie]

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

Basically for "ease of setup" (although this is a loosely defined
term!), Maarten was suggesting that the first user (one who is maybe
pretty much always logged in anyway) just runs the only PA server, but
runs it as a per-user daemon as normal. But that user customises their
default.pa:

e.g. create a ~/.pulse/default.pa containing:

.include /etc/pulse/default.pa
load-module module-protocol-native-tcp ip-acl=127.0.0.1

You should also do

touch ~/.pulse/client.conf

(I've not checked the syntax but I think it's right).

Then for the other users write a /etc/pulse/client.conf with:
default-server = localhost
autospawn = no


The primary user's personal client.conf overrides these settings, but
all other users get them.

You may also need to disable the XDG scripts from running at login (the
start-pulseaudio-* scripts.... can't remember if this is handled or not
- either way the fix is simple, just edit the scripts and put a "[
"$USER" = "yourprimaryuser" ] || exit" near the top of them.


You also need to make sure that the primary user is in the "audio" group
such that they can always access the sound hardware.



With this setup, provided your primary user is always logged in,
everyone will have sound.

> Or preferably not over TCP/IP at all but using unix sockets?

Your primary user will go via unix sockets and get the benefits of SHM
for memory transfer (you should therefore run mpd as this user if you
run it).

The other users would use TCP.


In a full system-wide setup, all users could use unix sockets, but none
could use SHM for memory transfer, so there is still a tradeoff.

> Would this then solve the security issues mentioned on
> 
> http://www.pulseaudio.org/wiki/WhatIsWrongWithSystemMode

No. The system is wide open to abuse from all users.

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

Not quite sure what you're suggesting here but obviously for TCP
connections there is no concept of "user" unless you make PA support
e.g. SASL based authentication or something crazy like that (and please
see my previous, much longer explanation of things in reply to Ben's
email for why we'd get massively criticised if we started adding that
kind of junk to PA!). For sockets, we already have a "pulse-access"
group that is needed to be able to access it via a system-wide socket.

And as above, the "pulse" user running the PA deamon would need to be in
the audio group.

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

With the above suggestion of not using a real system-wide mode, just a
"primary user" mode, there would be no problem with module loading etc.
as that user is just a regular session... the security issues of
eavesdropping etc. as ever present of course.

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

Doing inter-user SHM validation is hideously complex. It's just not
something we'd want to ever contemplate.

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

He means there are no longer any "User" preferences. It's just "system".
Maybe you like the volumes louder than the other users on the system.
With the typical setup, volumes are per-user so switching logins is nice
and as you like it, not just "what the last person using it set it to".


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

Of course it is. That's the problem. If you share the system with
multiple users, you open up the ability for every user to eavesdrop on
"the sound system". If "the sound systems" is a shared resource they can
poke at each others stuff quite happily. I could run a parecord process
recording everything that came out the speakers and lock my session and
wait for you to have a personal voip call.

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

They would all be lost, and they do a bunch of different things... gotta
get on with work just now so can't explain them right now :D

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/