[pulseaudio-discuss] system-wide daemon

David Henningsson launchpad.web at epost.diwic.se
Tue Feb 9 22:14:02 PST 2010


Colin Guthrie wrote:
> 'Twas brillig, and David Henningsson at 09/02/10 21:52 did gyre and gimble:
>> I wrote down a few use cases here, I'm sure there are more:
>>
>> https://wiki.ubuntu.com/BluePrints/multiuser-soundcards-pulseaudio
> 
> For user Foo, the sound card sounds like it's dedicated for Foo. If this
> is the case the a udev rule should be written to ensure that only Foo
> has ACL rights on this file and any console-kit udev-acl callouts are
> ignored.

That makes sense, thanks. I added that reply to the blueprint.

> For user Bar, I feel this is invalid. Why should user Bar have the right
> to output a sound any more than he has the right to display a popup
> window on my desktop? 

Here's another analogy; what about the printer? If printers were
considered a part of the seat, then user Bar wouldn't have more right to
print a document either. (The corresponding spy-on-mic analogy would be
that someone puts a document in a scanner and another user scans it...)

But printers are more of a system-wide resource, and for some use cases,
so is the soundcard. And then, sharing makes sense. If another user is
allowed to print a document while I'm logged in, why shouldn't he be
able to play a sound? So would then the solution be to run PA as a
system-wide daemon, and possibly assign soundcards to it via udev?

> If either scenario is to be supported, then what I
> suggested elsewhere in this thread is still valid I reckon. i.e
> something needs to be run as the active user that acts as an agent for
> some kind of (system?) service that actually generates said alarm. The
> agent will be running as the active user and it will be responsible for
> playing the sound/displaying the popup.

Right, this would make sense for some use cases as well and worth
considering.

> As for multi-seat, this is already in hand. Console-Kit has support for
> multi-seat stuff (tho' it may not be complete - I'm not overly sure
> here). What may still remain to be done is to tag certain devices as
> being for particular seats so that console-kit/udev can apply the
> appropriate ACLs when the set becomes active for a given user. All the
> multi-seat stuff is below PA tho' We'll just honour what it tells us. I
> don't think we don't need to add specific support for it. 

And the way ck/udev tells PA what devices it can use, is through device
permissions?

// David





More information about the pulseaudio-discuss mailing list