[arch-general] PulseAudio in [testing]

[C Anthony Risinger]

2010/11/27 Ng Oon-Ee <ngoonee at gmail.com>:
> On Sat, 2010-11-27 at 13:01 -0600, C Anthony Risinger wrote:
>> On Sat, Nov 27, 2010 at 1:47 AM, Philipp Überbacher
>> > 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.
>
> This has nothing to do with pacman. You can have many sound servers
> installed, you just have to choose yourself which to run. And ALSA is
> not a sound server. Pulseaudio and JACK are. I run both, at varying
> times, on the same machine.

well, that's why i said "library"; i know the user space alsa is not a
server.  the fact is, as you've stated, only one impl. can comfortably
run at any given moment... but yeah, it doesn't matter too much i
guess :-)

i was referencing the fact that package managers (including pacman)
are pretty one-track minded, and cannot cope with internal variations
of the same package whatsoever (causing a need for dynamic dependency
handling).  portage sort of handles it, with the SLOTS system, but not
really... in pacman (and others) a whole new package must be created.

so maybe a totally pointless question in the end, but was curious if
the *-pulse suffix would ever be dropped for some other scheme.

>> > 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?
>
> Refer to your own comments below. How does the kernel even come into a
> discussion on Pulse anyway?

yes there is much to learn :-)

i thought pulse ultimately was trying to replace the ALSA kernel API
as well, but sounds like i may have been wrong.

>> > 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.
>
> Yep. Simple version, ALSA manages the hardware itself (a tough job, and
> causes most breakages currently, hardware support on Linux, same old
> story), pulseaudio plugs in on top of that to manage ALL apps, so it
> sits between apps and ALSA. In the same way JACK does.

but there is still a difference between the alsa kernel API and the
user space API... they just happen to share the same name, but they
are very different [wikipedia]:

"Unlike the kernel API which tries to reflect the capabilities of the
hardware directly, ALSA's user space library presents an abstraction
which is as similar as possible across disparate hardware."

i thought pulse was using the kernel API directly, but again may be
wrong.  in this respect, PA is a peer to alsa-lib, not alsa...
everything (jack/oss4 included?) uses alsa at kernel level.

>> 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.
>
> Yeah, what does Ubuntu have to do with Arch anyway?

heh, indeed :-) that's what i thought.

>> 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.
>
> I've been following systemd as well, looks good (though BSD-style init
> is what we're all used to here). Will perhaps try it out soon. PA is
> stable, and IMO has been for more than a year.

yeah that's another can of worms, but it's one of about 3-5
technologies i'm really excited to reach fruition.  nice that PA is
w3rks for you too though, i'm definitely going to give it a shot very
soon.  thanks Ng, Jan, Philipp and everyone else for your time.

C Anthony