PulseAudio

[xiphmont at xiph.org]

On 2/27/07, David Zeuthen <davidz at redhat.com> wrote:
> 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.

I meant technically orthogonal.  It can be done regardless of session
vs. system.

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

Ah, so it boils down to a semantic argument... yes, that 'system
daemon' is what I am calling Pulse Audio, in that it will have most of
the actual mechanism in it.

> 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 could do it that way, the worry is the latency/complexity
introduced by the sound stream having to touch too many hands/endure
extra context switches before making it to the actual hardware.  We
are talking about, for the most part, the same conceptual
abstractions, but I'm talking about them all existing in the same
process space.  A 'system' pulse must, at a very minimum, exhibit full
session personalities/awareness to the apps.

We're not arguing at all about the end-functionality in this case.

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

Actually, the driver *does* know it's silence because of the way the
transactions are handled by ALSA; if the device is open and no app is
feeding data, ALSA can be told to supply silence (or hold last value,
or an y number of things).

As for 'eating power', if it's a hundred mA, I fully agree with you.
If it's 10mA, I'm less sure.  If it's a mA or less, I laugh at your
requirements unless it's OLPC :-)

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

I know it's fashonable to make this a session preference, but it isn't
really. This is a decision it makes more sense to give to root.  But I
don't care enough to argue.

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

Well, I argue for it being a system (not desktop) setting as it has to
do with a system resource.  But enh.

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

..and what happens during the transition?  It depends on the settings
of each user combined....?

> So I take it you can point to a kernel driver that doesn't wait N
> seconds. Return to dealer :-)

None of the USB sound cards wait, because USB shuts them down
immediately upon last transaction finishing.  For other cards, it's by
driver and they're not consistent.

> more seriously, you do know that runtime
> power management isn't really set in stone in the Linux kernel yes?

I know, never was.  Brand new system every three years.... My thinkpad
could suspend properly in 2004 :-(

> Anyway, the point is that this is the behavior we want, don't you agree?

I'd opt toward 'smoothest behavior in all cases' unless demostrated
that a powered sound chip is causing measurable drain.  That's not an
argument against full options being available regardless.

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

Oh, well if that's an accepted part of the design, my work is easier.

Monty