[pulseaudio-discuss] system-wide daemon

[Markus Rechberger]

On Wed, Feb 10, 2010 at 7:14 AM, David Henningsson
<launchpad.web at epost.diwic.se> wrote:
> 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?
>

Also imagine TV tuners, webcams are basically handled the same way.
One user might want to capture a TV movie, while the other one doesn't
need access to it.
The ck assignment would not be valid for this.
Now imagine we have a DVB device, multiple users can access the same TV channel.
While another user might stream or capture the TV content the user
sitting behind the PC might watch
the current tuned in TV channel. This is a not so unlikely scenario
with our devices.
This is also just another example where the MS-DOS like single user
scenario does not fit.

Best Regards,
Markus

>> 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
>
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>