[arch-general] PulseAudio in [testing]

[C Anthony Risinger]

On Sat, Nov 27, 2010 at 1:47 AM, Philipp Überbacher
<hollunder at lavabit.com> wrote:
> 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.

i guess i was trying to draw the parallel that with some things there
can only (easily) be one choice.  a better example probably would have
been the choice between say nvidia/nouveau -- "there can be only one!"

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

yes i'd agree 100%; to clarify, i'm not asking about gnome/.../... in
particular, my inquiry was based on the observation that only one
"sound server" (or user-space library) can comfortably run per system,
and i was curious as to how that would unfold in terms of pacman/etc.

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

yes this is really the best, and maybe this is the norm; i just
thought i remembered some packages being exclusively one or the other
(mplayer?), but things may have changed.  i don't even have any media
players installed; the X360 + local shares do this work for me :-)

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

ok, i was thinking that PA was eventually going to have new kernel
bits included as well.  i know (IIRC) that ALSA is a kernel API, and
also a userspace API... distinctly separate.  programs are normally
linked against the userspace API vs. using the kernel directly,
correct? and PA has no intentions of ever reaching the kernel in any
way shape or form?

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

ok, i suppose i will need to do some more research on all of these
components and how they interoperate, thanks Philipp.

my only concern is that 99% of the negative feedback is based on
ubuntu this or that, usually from years past... ubuntu pretty much
jumped the gun; i really like the growing trend of services with DBUS
unification, and i think this is a Good Thing for
management/security/flexibility.

PA appears to be quite stable at this point, and it's great that apps
work with or without.  somewhat unrelated, but these same questions
will rise again, and more fiercely, once systemd is stable and
mainstreamed (which is slated for fedora, and IIRC being considered by
debian/ubuntu)... the landscape is changing for the better.

C Anthony