PulseAudio

[David Zeuthen]

On Tue, 2007-02-27 at 13:28 -0500, xiphmont at xiph.org wrote:
> On 2/27/07, David Zeuthen <davidz at redhat.com> 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