Small subject alteration. Paul Perkins said: > Well, the WIKI page on ALSA config files at > > http://alsa.opensrc.org/index.php?page=.asoundrc > > has evolved to where it is beginning to sound useful. But it doesn't take you > all that far, and it needs explanations of basic terms like "pcm" (in its > peculiar ALSA meaning), "slave", and "plugin". The "detailed" material on > plugins it references > (http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html) is just a > list of plugin names and plugin argument names, padded with some boiler-plate > text that rarely adds anything that isn't implicit in the names. > I have to say, this has been an issue for me also. Things have improved muchly in the last year, but there still is a way to go. There's a lot of translation needed between Those-Who-Read-The-Source and Those-Who-But-Point-n-Click. I'd like to contribute to the documentation. One thing i've been bothered by. (Maybe this doesn't bother LISP hackers, i dunno) Not enough example .asoundrc files. The few I find are always useful to me, but i can't find very many. Maybe people don't want to pollute the list, maybe everybody else is smarter than me, who knows. I'll make an offer: Mail me (cliffw@xxxxxxxxxxxxxx) your .asoundrc file + name of hardware. If you have a quick example of What It Does For You, email me that too. I'll attempt to boil off the excess and add something useful to the wiki. cliffw > I don't measure the power of a computer or of software by what it can do. I > measure power by how much faster or better I can do what I want to do with > the computer or software, than without it. Including the learning time. By > this definition, good documentation makes software more powerful, and > documentation that requires a lot of hunting around and trial-and-error to > make sense of, makes software less powerful. > > As for how far I am willing to go, that depends on what I expect to find when > I get there. I'm a pretty good C and Python programmer with a smattering of > C++ and Java, I'll edit fstab, modules.conf, XF86Config, and so on with vi > when I have to (but these days count it as a bug in the distribution when I > do have to). I use Linux for pretty much all my computer activities these > days, except music recording / synthesizing / effects / mixing. I'd like to > use Linux for that as well, but it just doesn't seem to be ready yet. When > Ardour is stable it might be time for me to make another attempt to switch > over (from the evil empire os). Music is enough of a challenge for me, I > don't need to be on the software bleeding edge at the same time. > > On Sunday 22 June 2003 11:55 pm, Patrick Shirkey wrote: > > Paul Perkins wrote: > > > On Friday 20 June 2003 01:30 pm, Patrick Shirkey wrote: > > >>Paul Perkins wrote: > > >>>... and I'm still waiting for the day when someone explains ALSA > > >>>configuration files > > >>>in a way that I can understand.... > > > What don't I understand? I would like to see each concept that the ALSA > > > configuration file language is intended to be able to express, and then > > > the syntax used to express that concept. Then some examples with clear > > > explanations of why each thing in the config file was put there. As in a > > > good programming language tutorial. What I've seen instead is a lot of > > > chunks of strange-looking syntax "explained" by saying "try stuffing this > > > in <some file somewhere>, and good luck." Which leaves me blundering > > > around in the dark, hoping to get lucky :-). > ... > > "Don't bend the > > spoon... Let the spoon bend you..." > > Maybe if I had any idea what you mean by "let the spoon bend you" I would also > find the ALSA documentation crystal clear ;-). > > Paul Perkins > sigmotto: Liberty is theft. > > > >
