PulseAudio

[David Zeuthen]

On Tue, 2007-02-27 at 15:32 -0500, xiphmont at xiph.org wrote:

> [stuff why we should support OSS in the default install]

As I said, it's not my call whether the Fedora project should support
this in the default install. For the record, if you want to run GTK 1.x
apps you need to install compat packages. That's a decision that the
Fedora project made after doing cost/benefit analysis etc. Things like
'cost' included 

 - including GTK 1.x meant fewer people ported to GTK 2.x
 - the apps we include in the distro were all migrated
 - size/complexity of maintenance
 - and things like...

If supporting OSS out of the box just works and is cheap to maintain,
hey, go for it. If there's a huge cost.. then.. back to your cost/
benefit analysis. 

Personally, I'd like OSS to just work, don't get me wrong it would be
*nice* to have but not something that should dictate an architecture and
make it *very hard* to do future stuff (running PA system-wide).

> Typing 'padsp {insert wrapped application here}' does not count as
> 'compatability'.  If it did, we'd already be done and the world would
> be saved.
> 
> As for an emu daemon, we'd need to implement f-u-s awareness.  The emu
> daemon is also a system daemon, and those are apparently evil these
> days.

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

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

> And there's a simple problem of physics,  Unlike X we can't just 'fix'
> the pop of a sound card when the device is shut off and restarted.  If
> we go the session route, we will live with the pop forever.  Think
> about what a sound card output stage looks like....

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. Because
saving power is very important and may in the future be a requirement to
sell to governments.

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. Further, only few sound card drivers do
this already, I can only think of the one for OLPC hardware.

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

Nope.

     David