Colin Guthrie schrob: > 'Twas brillig, and Mark Cross at 26/07/10 15:23 did gyre and gimble: > > 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. > > 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.
That sounds like resources can never be shared. Which is what Mark and I
are looking for.
> 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.
Yep, but maybe CK isn't such a good police^Hy.
> > 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?
None.
Alsa supports[1] one application playing audio at a time.
PA supports applications of one user playing at a time.
There's an obvious next step, and PA is not taking it.
(Not blaming the PA folks. PA certainly already is a hard task as-is.
And in the worse-is-better spirit, getting PA work for "desktop" usage
and worry about the rest later probably indeed is the best way forward.
But I still feel it's a pity.)
> > 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.
>
> 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.
This is exactly what I'm running here. Works well enough.
@Mark: See the "My computer thinks I'm schizophrenic.." thread from
mid-April, I posted the config there (but it's basically what Colin just
said).
> 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).
...which I don't care about, because all the users are me, but otherwise
it's still something PA can't cope with at all.
> 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.
Urgh, I hate that reasoning. Personally I don't care what Windows or Mac
OS do. I expect Unix to do the Right Thing. Which, in this case, would
be "(allow to) manage the permissions of different users and make sure
they play nice with each other", not "allow only one user to access the
compu^Waudio system at a time".
PA might be the way there. At least, if PA succeeds, it'll purge HW
dependency, which is a giant step forward. But currently, I feel PA is
severely lacking in Unix spirit.
regards,
Jan
[1] for demanding interpretations of "support"
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
signature.asc
Description: Digital signature
_______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
