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