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

[Colin Guthrie]

'Twas brillig, and Ben Bucksch at 13/11/11 17:38 did gyre and gimble:
> On 13.11.2011 15:40, Colin Guthrie wrote:
>> 'Twas brillig, and Ben Bucksch at 12/11/11 20:56 did gyre and gimble:
>>> 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.
> 
> This doesn't allow the situation where you just start the machine, no
> user logged in (because it's acting as server), and you can play music
> with your tablet, loudspeakers connected to the computer.

Yes it does. I've mentioned several times that the login session, e.g.
gdm etc. would be considered a "user" in this scenario. The same
workings (if a gdm is not run) would apply for e.g. getty's etc too. But
in this scenario it's up to the system administrator to say that the
"login" user does or does not run the agent. After that, it's whichever
real user who logs in that has the choice as to whether or not to run
the agent.

My first example was specifically about accessibility. In this case the
login screen really needs to connect to the underlying accessibility
framework so as to offer the less able user to login easily.

> I'm just asking that the system-wide setup of pulse is properly supported.

This is fine. It's as supported as it needs to be. But as I've gone to
pains to explain, it has fundamental limitations in design that limit
it's usefulness.

I genuinely believe that the approach I've outlined is a better model
for supporting the kind of use cases you want, plus ensuring security
and utilising all the other bits that fit very well in PA just now. I
just think one of the aspects of this plan has not been clearly enough
explained, so sorry about that.

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/