[pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions

[Colin Guthrie]

'Twas brillig, and Ben Bucksch at 12/11/11 20:56 did gyre and gimble:
> On 12.11.2011 21:21, Colin Guthrie wrote:
>> Ben Bucksch wrote:
>>> On 09.11.2011 11:56, Colin Guthrie wrote:
>>>> Now consider two users on an accessible system: One is visually
>>>> impaired
>>>> the other is not
>>> - at the same time. OK, but that's really an unrealistic case now.
>> No I meant two users on the system. Only one uses the machine at any
>> given time.
>>
>> My point was mainly that the control over whether the sounds from the
>> underlying services (be it mpd or some accessibility layer) should be
>> user choice, not forced upon them.
> 
> Yes, sure. And with pulse, that's trivial: *If* such a daemon really is
> running and disturbing, it's easy to silence via pavucontrol.

Yes, assuming the daemon is connecting to the users PA daemon.

>> mpd as a daemon shouldn't be forced upon any user
> 
> Please check the scenario I outlined again (copied again below).
> 
> That was a real case, of a friend who dropped pulseaudio, because that
> wasn't workable.

With the design I outlined your friend wouldn't have had any problems.
I'm wondering if I'm not explaining it correctly....


>>> More realistic is: An average couple, he is a unix geek. He has a
>>> notebook and a tablet. The notebook is connected to speakers, running
>>> mpd for music. Tablet is running mpdroid and controls the mpd.
>>>
>>> The notebook has 2 users (but never at the same time), so the geek
>>> doesn't want to log in to any particular account just to listen
>>> music, but wants mpd to work irregardless of the logged-in user.
>>>
>>> There's no conflict, because if the music disturbs her, she'll just
>>> turn around and tell him to stop. Which, I think, will be true for
>>> almost all cases where you have 2 humans around the same computer at
>>> the same time. 
> 
> If you don't know mpd, please check it out. The whole idea is that I can
> control from several clients, but the playback is done by the server.
> And it's *really* cool, esp. combined with an Android tablet.

I'm fully aware of how it works and as far the control and input stages
go, that's perfectly fine. That doesn't mean that it is architecturally
perfect. and I feel that having a system-wide daemon outputting sound
regardless of who is logged in is fundamentally the wrong approach.


In the scenario I envisage, you'd still have the central mpd process,
and you'd still have mpd clients connecting to select what is played.
The only difference is that rather than the daemon process actually
actively outputting sound, it is separated into an "mpd output agent"
process. This process needs to run and connect with he daemon to do the
output stage. Any client could still log in and do the control/selection
stuff, and any active output agent will simply and dumbly output the sound.

Each user on the system that agrees to let mpd play will run the output
agent as their own user (and this includes the gdm user whose
participation in the mpd setup is a system administrator choice). It
then thus connects to their own PA daemon and all is well in the world.


I'd draw a diagram but I'm about to head out the house, but hopefully
I've cleared up any confusion you have. It doesn't match the scearnio
you painted 100% but IMO it gives full control by default but still
gives individual users the right to opt out completely. As I said, this
approach is something that applies generally beyond MPD and just sits on
top of all the underlying security systems without having to turn PA
into something it really shouldn't be (see all my previous mails about
this) and something we'd be very widely criticised (for good reason)
were we to implement.

You have to appreciate that everyone's problem is the most important to
them, but we, as an upstream project, have to consider a wide range of
issues, use cases and problems. I think the design outlined meets all
the practical needs of the typical mpd setup while not compromising
anything regarding overall security and design of PA itself.

Col




-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/