Hi, > Of course! This is because Alsa is not a part of the kernel. Once it > becomes a part of kernel, it will be the same like OSS in this respect.
Pff, nothing would change, if alsa is in the kernel? I don't see why this should suddenly make things easier? I don't see the necessity to put in into the kernel, if it installs nicely from a different directory. Compiling the alsa modules for the drivers and installing it with "make install" does work quite easily. Debian even ships alsa packages with precompiled drivers for the kernel. Installation of alsa-lib afterwards is the problem. The users asks himself, how to setup the modules for the init script, what the heck happends in asound.state, how do I write my own configuration files. And what can I do with all those hw, plughw, share, multi, whatever plugins. And I have to admit, I'd like to read about that, too, cause I have no clue and I actually have better things to do right now than reading the alsa source. Anyway I learnt how to setup a device, configure it and happily read/write to it. But until know I haven't seen what else ALSA can do, that would make it really different from oss. Apart from the possibility to use smaller framesizes, but that's possible with oss too, in case the driver supports smaller framesizes. > I have to completely disagree with your statement here. I could not care > less for BSD, Solaris or any other flavor or *nix. I use Linux and that Luckily the authors of some sound applications thought different. As Paul already stated most of the early ones come from IRIX. > I would much rather see Alsa developers invest their time into > perfecting Alsa's architecture, than use the same time for porting an > API that is yet to be completed/widely used to other OS's. You're probably happy with ALSA on Linux/i386. What about Linux on other architectures.. Cheers, Alex -- Kindness is a language which the deaf can hear and the blind can read. -- Mark Twain