[arch-general] PulseAudio in [testing]

[C Anthony Risinger]

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.

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

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