On Tue, 2007-02-27 at 13:28 -0500, xiphmont@xxxxxxxx wrote: > On 2/27/07, David Zeuthen <davidz@xxxxxxxxxx> wrote: > > > So it's like this. For *modern* Linux desktop we've been moving > > functionality from system-wide daemons into per-session daemons *simply* > > because system-wide daemons have a number of problems. > > Justification by cargo cult. Oh please. Keep this discussion technical. > Here's a few reasons per-session Pulse is > [relatively] a worse idea: > > You lose state on switch. > Transitions are abrupt and 'poppy'; think of the X mode changes upon switch. X is getting fixed. See Keith's blog for this http://keithp.com/blog/kernel-mode-drivers.html See also below. > Per session is harder, yields inferior results in the long run, and > gives us no path to move to immediately. Either we do things right or we don't do them at all. No more hacks for benefit in the short run. Please. > Impossibility of emulation. Emulation is not optional. We do not > make forward progress by throwing all the current users under the bus. > This is *the* reason esd was a resounding failure. Users can use LD_PRELOAD for such broken apps that we can't patch to live in this century. We all know that /dev/dsp is fundamentally broken and no-one but people living stuck in the 90's are using it. We're a *free software distribution*, we don't have to support legacy crap the nice way. If you want, use LD_PRELOAD hacks. Or some emulation daemon that can forward the stream from then open(2)'er to the right PA instance (not hard). > > Another problem is that if you have system-wide daemons you need to > > coordinate clients with different identities; e.g. you suddenly need to > > label your objects and make sure that an object created by uid 500 > > cannot be manipulated by uid 501. Things like that. Does PA handle that > > already? > > No, it does not. Heck, so uid 501 can poke the streams created by uid 500? That's a show stopper just because of security implications. Do you disagree? > It will also not currently handle f-u-s as a session > daemon either. That's only because PA decides to open the device directly and haven't been taught to give it up on session inactivity. That's not hard to change and it's the right thing to do *anyway* since we probably want a default policy where audio is muted from inactive sessions just like video is muted. Heck, we're getting revoke() soon (see #230006) so whether the PA instance in a session likes it or not it's going to have access to the sound device revoked. It just needs to cope with that *just like* it needs to cope with devices being hot-removed. > > How is it going to work with multiple sessions? I > > don't think there's anything "easy" about this. If it was easy, wouldn't > > you have RPM's for us already? ;-) > > The code is easy. The politics make me want to walk away and never look back. Well, there's no politics here apart from wishing not to introduce short-term hacks that will haunt us for ever. See X.org mode setting in user space for a brilliant example of how this hack is STILL HAUNTING US in 2007. Ding ding ding, it's 2007 already! > > I think what you want is some system-wide private PA mixer service that > > only per-session PA instances can connect to over a private protocol. > > That is actually one possibility up for consideration, but I think > needlessly complicated. The problem is not making Pulse work well > with f-u-s-- the problem is keeping ALSA, ESD and OSS access working > with f-u-s. Remember-- that's everybody right now. Yes, we need to sort out this audio situation. Right now PA, until it's fixed in a sensible way, makes f-u-s not work so we can only do one of them. That's not my call though. What is the view of all this from PA upstream? I talked a lot to Lennart at LCA about this and he said system-wide pulse was a non-starter exactly for the reasons I listed. David -- Fedora-desktop-list mailing list Fedora-desktop-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-desktop-list
