On 2/27/07, David Zeuthen <davidz(a)redhat.com> wrote:
On Tue, 2007-02-27 at 16:13 -0500, xiphmont(a)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
I think ideally we'd have a system-wide daemon that all
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
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
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
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
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
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
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.
Oh, well if that's an accepted part of the design, my work is easier.