PulseAudio

[xiphmont at xiph.org]

On 2/27/07, David Zeuthen <davidz at redhat.com> wrote:

> Let me repeat again: both are ugly as hell because OSS is ugly as hell.

I'm not arguing with that.  We need to support it regardless, or the
march of forward progress will fail like it did last time.  We're not
in a situation where we can force bitter medicine on users 'for their
own good', and we shouldn't try.

> Whether we as a distro want to keep compat for these around in the
> *default* install is a separate issue and up to the Fedora project at
> large.

No, it is entirely the same issue.  If only one application a user has
been relying on daily for years breaks due to 'forward progress', that
user is going to hate 'forward progress'.  I am among the people who
regard computers as tools: you use them to get work done.  You don't
use them because you love staring at glowing objects or because all
the tech is just so damned nifty.

And very few things piss off a tool user like a tool breaking.  Being
informed it was for his own good does not make him happier ("just
write to the author and tell him to fix his broken crap!  We're trying
to march toward the sunrise of a glorious tomorrow here!").  This is
not to say that's not going to happen occasionally anyway, but to
claim it's unimportant or obstructionist is ludicrous.  This is not
off topic.  It is central to the problem of software adoption in a
community that is not captive.

> > Say 'ESD' in a room full of Linux users five years ago, and the first
> > thing anyone thought was 'Oh, it's that thing I have to kill so all my
> > sounds apps will work again'.  If we repeat that mistake with PA, PA
> > will also become reviled.
>
> I don't understand this. OSS compat is possible through two mechanisms
> already. Plus I have a lot of faith in the PA developers not to screw
> up.

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.

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.

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

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

Monty