[arch-general] PulseAudio in [testing]
C Anthony Risinger
anthony at extof.me
Sun Nov 28 03:36:21 CET 2010
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
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
> 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.
More information about the arch-general