PulseAudio

[David Zeuthen]

On Tue, 2007-02-27 at 16:13 -0500, xiphmont at xiph.org wrote:
> > 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--

Not really. We're arguing what's best to do - either a system or session
PA and this demonstrates that OSS compat has nothing to do with that.

> 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.

Right.

> > > 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.  

I think if you building an appliance

 - it's not too much work to start another instance of PA; if this
   can be done on-demand (as you didn't argue it couldn't) then it's
   all automatic
 - your appliance would probably run unprivileged (See: flumotion)

> 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.

I think ideally we'd have a system-wide daemon that all per-session PA's
connect to which does mixing and handling emulation devices. Perhaps,
for you, that is PA (with few modules loaded) and we're talking about
the same thing. Such a thing would be ConsoleKit aware, e.g. it would
enforce (tweakable) policy such as muting inactive sessions.

Still, I _do_ want PA in my session so I can do all the "compiz for
sound" things (settings) and, in particular, I don't want other users to
be able to tweak my streams (security).

> > 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...

Yea, but the chip is powered up and eating battery as long as someone
has the device file open - the kernel driver has no chance to know it's
silence and it shouldn't. (actually some drivers power down parts of the
chip depending on whether capture/playback device files are open.)

> > 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.

I think it's a user preference really. We have this thing in g-p-m to
tweak this desktop-wide preference 

 http://people.freedesktop.org/~david/g-p-m-prefer-power-savings.png 
 (for some reason this is not in Rawhide - I'll investigate)

 (actually these are two settings; one for when running on battery
  that defaults to TRUE; one is for running on AC which defaults
  to FALSE. Which I think is sane).

but perhaps Pulse itself could offer a setting whether to use the
desktop-wide setting or the user could specify a timeout. 

My point being, it's a user setting. If the user says "never turn off
sound card when there is silence" (by some setting) then the in-session
PA just streams silence to the system-wide daemon or kernel driver.

> > 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.

So I take it you can point to a kernel driver that doesn't wait N
seconds. Return to dealer :-) - more seriously, you do know that runtime
power management isn't really set in stone in the Linux kernel yes?
Anyway, the point is that this is the behavior we want, don't you agree?

> > > An earlier question still stands, and it is central: does UID ==
> > > console session ID?
> >
> > Nope.
> 
> How do you regulate /dev access?  

Access in Linux is per-user/per-group and that's hard to change. The
$XDG_SESSION_COOKIE thing is simply a way for a system-wide process to
identify what desktop session a process belongs to. It isn't used to
enforce any security whatsoever.

> A user logged in twice would hand
> both sessions full access.

Yup.

     David