On 2/27/07, David Zeuthen <davidz@xxxxxxxxxx> wrote:
On Tue, 2007-02-27 at 16:13 -0500, xiphmont@xxxxxxxx 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 -- Fedora-desktop-list mailing list Fedora-desktop-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-desktop-list
