[arch-general] PulseAudio in [testing]

[Philipp Überbacher]

Excerpts from C Anthony Risinger's message of 2010-11-27 08:11:04 +0100:
> 2010/11/27 Ng Oon-Ee <ngoonee at gmail.com>:
> > On Fri, 2010-11-26 at 23:02 -0600, C Anthony Risinger wrote:
> >> On Nov 26, 2010, at 10:57 PM, Allan McRae <allan at archlinux.org> wrote:
> >>
> >> > On 27/11/10 14:51, C Anthony Risinger wrote:
> >> >> Good to see the overwhelming positive lean; is pulse being considered
> >> >> for an eventual default by chance?
> >> >
> >> > Almost nothing is default on Arch...
> >>
> >> Beh you know what I mean :-)
> >>
> >> i.e. "recommeded", only-one-or-the-other packages become PKG/PKG-alsa
> >> instead of PKG/PKG-pulse, package groups use pulse builds, etc etc...
> >> or am I off base?
> >>
> >> C Anthony [mobile]
> >
> > Its a bit similar to asking if compiz will be 'default'.
> 
> ehm... sound handling is a pretty basic requisite for the essential
> functionality of many applications, not to mention my limited
> "hand"ful of human interfaces, and is usually related to direct
> hardware access.  not really that comparable imo, buuuut maybe on some
> vague or undefined level ;-)
> 
> i'd say the ubiquitous use of opengl would maybe present a similar comparison.

I disagree, sound handling is only essential for audio playback and
production programs, and the later don't and won't use pulse. Programs
feeping and beeping away all the time are an annoyance at best, a
problem at worst.

> > Its not an Arch decision anyway
> 
> sure it is.  we made a python decision regardless of upstream [app]
> preparedness.  this is just an example of fracturing nature of free
> software; several options can fill a singular need.  applications may
> choose one, the other, or the superposition that is both/neither.
> Arch's role comes into play when a particular need can only be filled
> by at most a single option.  not the best analogy, but in python's
> case this is the `python` name; it could be python2, or python3, but
> not both, and the package tree must compensate.  i was under the
> impression that pulse/alsa/etc. are of this type; only one is at the
> bottom level directing hardware, others are supported by layers of
> compatibility and indirection.
> 
> by all means lmk if that's not the case, as i haven't used pulse since
> the 'buntu days, though i try to keep up on it's progression.
> 
> > what will happen in future is that upstream apps will
> > either be exclusively pulse or at least prefer pulse. Meaning libpulse
> > will almost always be pulled in anyway, and at least under gnome a fresh
> > install would use pulse.
> >
> > So you should ask Gnome. And the answer is that yes, it will be default
> > on Gnome. If you do not use Gnome, then only if the apps you pull need
> > it.
> 
> indeed.  well i don't use gnome as i'm part of the e17 crew :-), but
> yeah, unrelated.  what i am asking, is whether or not
> one-or-the-other-only apps (aren't there such cases?) will assume the
> name APP, APP-pulse, or APP-alsa, or ...., or .... in time, or what
> the game plan is for this longish term.

Gnome isn't Linux, Gnome is primarily a DAU-top. I don't see why gnome
should govern the direction of every distribution. Yes, ubuntu decided
that they want to follow and build on gnome, their release cycle etc.,
but we're not ubuntu.

> when the decision is a compile-time choice (this is what i mean by
> "default" in Arch), will apps use pulse via alsa, or will apps use
> alsa via pulse? what is arch's stand here?  am i missing some critical
> information that would render my questions nonsensical?
> 
> just looking for further understanding, feel free to break into a new
> thread, throw sharp objects, etc.
> 
> C Anthony

I hope that adding PA at compile-time won't mean PA will be required.

The piece you miss: PA depends on alsa, it builds on alsa, it can't
replace it. At hardware-near levels there's still alsa at work. If you
use alsa via PA, then you go alsa-PA-alsa.

Btw., last time I checked it was not recommended to program using the PA
API, so unless this changed, developers are still supposed to write
their programs for alsa or whatever else.

--Philipp