[pulseaudio-discuss] system-wide daemon
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:
> 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
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
> 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
More information about the pulseaudio-discuss