2010/11/27 Ng Oon-Ee <ngoonee@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