[pulseaudio-discuss] Multiple users (kde) on Debian

[Mark Cross]

Colin Guthrie wrote:

> 'Twas brillig, and Mark Cross at 26/07/10 15:23 did gyre and gimble:
>> Colin Guthrie wrote:

>> So, there must be a way "supported by maintainers" to have two PA
>> instances form two users that share access to the sound system.
> 
> Sadly there is no officially recommended way to do this. This is
> actually enforced at a lower level than PA with ConsoleKit ultimately
> being responsible for writing the ACLs on the device nodes (via udev)
> used for the sound h/w.

We are talking of two instances of PA here, saying that the responsibility
is somewhere else (in CK), looks like a way to squirrel away the
responsibility to do the "right thing". If user1 "validates" access to
user2 (pahost + concept), what's the fuss?
 
> ck-list-sessions will tell you which user is "active" and typically this
> user will get access to various different resources on the machine by
> virtue of them being active.

Hmmm, yes that is working. On user2 logging-in and getting it's "Session"
as active, is able to play sounds. On switching with CTRL-ALT-F7 and CTRL-
ALT-F8 (or using switch-user) the corresponding "Session" changes state to
active and is allowed to play sounds.

However, this concept of "active" deals with the logged-in user, there is
no "concurrency" in it. Each user is switched "on" or "off" as needed.

> PA simply listens to messages from CK and gracefully releases it's
> control of the devices when it's not supposed to have access. In reality
> we're just being a good citizen in this regard.

Yes, PA should acknowledge CK messages and act accordingly. I don't know if
"demanding" "exclusive, unchallenged" "ownership" of the sound hardware is
being a "good citizen".

>> The problem Pulseaudio was supposed to solve was to have mixing of
>> several streams, but in doing so, PA took total ownership of the sound
>> hardware, not allowing any other service to access the hardware, not
>> even a second instance of PA. That have just shift the mixing issue from
>> ALSA to PA, with seemingly equivalent basic problems. Yes, it has
>> several interesting and useful features, but I wonder: what is the
>> "supported" way to have several services access the sound system?
>> 
>> As the developers decided to completely take ownership of the sound
>> hardware:
>> 
>> Shouldn't exist an option like: [ xhost +local:user2 (X-server) ] for
>> PA?

> In theory this would be possible. There are however two basic problems.
> The first is that a physical socket file patch is currently used. This
> could be changed perhaps to be a more abstract socket, but as things
> stand, user2 would need to have physical write permission to that socket
> (there are various ownership checks and such in the code).
> 
> But if user2 could access user1's PA socket, and he had access to the
> "cookie" used (~/user1/.pulse-cookie), then user2 could output sound to
> user1's PA daemon.

Linking the "cookie" (~/user1/.pulse-cookie) is easy enough, what else is
needed to "access user1's PA socket"?

> If user1 were a member of the audio group, then even if user1's session
> was not active (according to console-kit), he would be allowed to access
> the sound devices by virtual of them being group writeable.

Not having any user as part of the "audio" group is a PA recommendation:
	http://pulseaudio.org/wiki/FAQ

    Section 3 - Troubleshooting,
    Item 10 Sound doesn't work when switching users
     "  By removing all users from the "audio" group (the PulseAudio server
        still runs in the "audio" group), PulseAudio is able manage access
        to sound devices (/dev/snd/*) amongst multiple users with the help
        of ConsoleKit.  "

That enforces the concept of PA being the owner of (/dev/snd/*), so, it
should be PA who should deal with this "concurrent" situation IMO.

Also, "audio" group ownership creates this kind of problems:
	http://swiss.ubuntuforums.org/showthread.php?t=1417647&page=2

> A perhaps simpler (and slightly less efficient) mechanism to enable this
> is to simply enable networking support for the primary user (either
> without authentication or with a copied cookie file). Then set
> "default-server=localhost" in the client.conf of other users.

No, that will create this "rather confusing situation occurs":
http://www.mail-archive.com/pulseaudio-discuss@mail.0pointer.de/msg06635.html

So, using such option breaks normal "user switching".

> Of course the same problems regarding the ability of user2 to know what
> output user1 was making and generally sniff or otherwise interfere with
> them still exist (and user2 would also not be able to use SHM etc. too).

I rather see this "sniffing" issue rather "inconsequential" IF user1
specifically has to validate user2 access. After that, user1 will know,
as he has enabled such access.

Besides, what is the issue with the output? Having the sound of a
"Brittany Spears song" playing in the speakers is so annoying?
Doesn't PA have the ability to mute individual streams?
Just present user1 the running streams of user2 in pavucontrol and allow
him to mute as needed.

The only (remote) issue is with grabbing the "mic", which user1 has to enable.
But, there isn't the ability to control individual recording streams in
pavucontrol as well?

Just do the opposite, mute by default, and allow user1 to unmute as needed/desired.
 
> I think a pahost +.... syntax would be nice, but it's not something that
> is currently possible OOTB due to the way in which PA follows the
> 'active' user around.

Yes, it would be a good thing to implement.
 
> Also most people expect to get exclusive access ot the sound h/w when
> switching users (it's how it works on Windows and Mac OS) and that is
> therefore the case we really want to get right, even if other, more
> exotic, scenarios are not easy to achieve.

Gee, following the "lead" of Windows, which wants only one user to use
the computer to make sure each user pays for the software, doesn't seem
the right "recipe" to apply to a multiuser Linux system.

-- 
Mark Cross