On Thursday 20 May 2010 21:25:36 Canek Peláez Valdés wrote: > > What doesn't work is PulseAudio, actually. Too many problems with it. > > Pulse is simply broken by design; it's too far from the kernel to be any > > good. > > If I may use (most of) your words: "Well, it works here. It's been > rock-solid through months." And with various use-cases, if I may add. > > Can you elaborate why the audio architecture has to be close to the > kernel? The part that talks to the hardware obviously has to, but why > the part that handles the features, the mixes, the virtual devices? > I'm under the impression (correct me if I'm wrong) that it was one of > the major reasons to leave OSS4 outside the upstream kernel; too many > stuff in there that belongs in user space. It sounds reasonable to me.
Well the general rule of good design is that a daemon the user will use to tell to do $STUFF is a daemon and runs in user space. Like wicd - you tell it to please stop using the wireless interface now that you have plugged in an ethernet cable, and all this happens in userspace. The daemon tells the kernel which drivers to activate and with what parameters (grossly simplified description). The kernel is a big fat box with drivers in it, and it also knows how to do neat things like scheduling. From that point of view, that aspect of PulseAudio's design is indeed correct. Aside: I might not like PulseAudio much (I don't need any of it's new features) but it sure is better than esd or aRTs.... -- alan dot mckinnon at gmail dot com
