PulseAudio

[xiphmont at xiph.org]

> It's fine being a system daemon if it's a pure mechanism. Tell me, said
> emu system daemon knows the uid/pid of the opener of the device.

Yes.

> Presumably this emu system daemon would pass the file descriptor to the
> appropriate PA instance. How about that? (I tried to ask a few times but
> you never really answered)

That's orthogonal to the argument of system pulse vs. session pulse--
but yes it could talk to pulse either way.  It would not be passing an
fd (it's using shared mem), but that's an implementation aside.

> > Many applications of sound are more appliance-like than
> > application-like.  A session daemon is all fine and good until the
> > applicance has its appliance disappear.  The session daemon approach
> > does not allow even the possibility of appliance-like sound
> > applications.
>
> Either
>
>  - tell them to startup Pulse themselves; or better
>  - we automatically launch Pulse when needed (through libasound or
>    the system emulation daemon)

Either would be incompatable with the desktop arrangement; you've set
up a situation where serious audio software would be inherently at
least partially incompatable with working on a Gnome desktop.

Or we'd have to implement both-- a system Pulse for 'appliance'
applications that implements auth, etc, anyway, and a coordinated
cloud of session pulses.  Of course, since they're not really
sharing-- one pulse can have the sound devices at a time-- the
appliance pulse would lock out the others.

> We'll have the pop whenever we want to suspend the audio hardware and we
> do want to do that in the default install for laptops anyway.

We can suspend Pulse without suspending the hardware, BTW... the
kernel drivers will take care of pushing silence...

> Because
> saving power is very important and may in the future be a requirement to
> sell to governments.

Sure and there are cases where we do want the full-blown suspension.
Does that mean we mandate the lowest common denominator?  Most people
will not want the popping.

> Besides, your assumption that the sound card will be switched off/on
> during session switch (and cause a pop) is utterly wrong - the kernel
> driver for the hardware would of course only suspend the sound card
> after N seconds of no openers.

Demonstrably incorrect.

> > An earlier question still stands, and it is central: does UID ==
> > console session ID?
>
> Nope.

How do you regulate /dev access?  A user logged in twice would hand
both sessions full access.

Monty