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